MrMC

Lions, Tigers and Bears, oh my

Getting MrMC into Testflight has certainly been a test of our coding-fu. For those that do not realize, MrMC is big, really big. We have about 25+ dependent libs that are built. Some are static, some are dynamic. Then there's the main core codebase and on top of that, sprinkle binary addons for pvr. Like I said, big, very big and very complex.

Our first pass at submitting to Testflight uncovered some minor things that were easy to fix. bundle versions and such. A tweak here and there and presto, up it goes past the Xcode nanny.

This got us past Xcode nagging and let us actually upload to Testflight which promptly sends us an email about 'invalid binary', oh snap...

Lucky, the email from Testflight contained useful but cryptic information.

Non-public API usage:
The app references non-public symbols in MrMC: __tlv_bootstrap, _yp_get_default_domain.

Humm, cryptic indeed. Time to start grep'ing and figure out which bit is the offender. I suspected one of the libs so straight to them I go. I find the symbol "__tlv_bootstrap" in libssh but then it gets strange. Nothing in the code actually refs it, WTF? More digging and bingo, it's really a side effect of libssh enabling thread local storage via __thread and THAT is a private API under iOS/tvOS. Simple fix, pass -DHAVE_GCC_THREAD_LOCAL_STORAGE=0 and tell libssh to stop using it. Poof, no more '__tlv_bootstrap'. Time to find/fix, five hours.

The next one '_yp_get_default_domain' was samba, Ugg, I hate going into samba, she's twichy but hey, I'm a pro port-master... Simple fix again, force 'ac_cv_func_yp_get_default_domain=no' and '__tlv_bootstrap' bits the dust. Time to find/fix, less than one hour then a few more for regression testing. Yep, I'm good.

Next, some dynamic libs were being build with -fembed-bitcode but missing -Wl,-bitcode_bundle for linking. Luckily, we get good feedback from the email and it points us to the offenders, a bit of diddling with linker flags and double checks to make sure we have no regressions as a result. Time to find/fix/verify, one day. Keep in mind that part of these checks rebuilding ALL of our lib depends from scratch, runtime testing then upload to Testflight and wait for the results. Like watching paint dry. Each cycle is several hours.

The last one was a bit of a mystery and stumped us for more than a few days.

"Invalid Swift Support - The SwiftSupport folder is missing. Rebuild your app using the current public (GM) version of Xcode and resubmit it."

WTF ? We have zero swift code and we ARE using the GM version of Xcode. Finally, after trying all the 'similar' fixes that others did, I take out the axe and start chopping parts out. The resulting app would never run but at least it would point to the chunk that was removed. Bingo, find it on 1st pass. Something with the dylibs we put into Frameworks. We poke and poke and oh. Turns out that what Apple means when they say dynamic libs are supported in iOS8+ is dynamic FRAMEWORKS are supported, not raw dylibs. But wait, raw dylibs are ok for the swift libs that Xcode copies over. Really ? Come on Apple, eat your own dog food now. Grrr. ok, I can deal with that.

The cleanest quick solution was add a post packing run-script that runs after we pack dylibs into Frameworks. It converts the dylibs into a valid framework bundles and off to the races we go. No more "Invalid Swift Support". But wait, step two of this is fixing how the libs are loaded in code since now the name/path does not match the codebase name/path. Grr, three days on this while we come up with a reasonable solution that actually works too

Now, we can upload (yea) , get 'binary valid' (yea) but then we barf at "There was an error importing this build. We are working to resolve the issue." (boo). Every. Single. Time. Grr. More cryptic feedback. This is where we stand today and the next step is to call them up and start pestering them...

2015.11.24 update:

Well, it's about time. That last one was a doozy. Called Dev support, after a few round with level 1, elevated to a 'senior Advisor'. While I was waiting for more paint to dry, I had a thought (which could be dangerous sometimes). I remembered that doing an achive/export/developer with bitcode gen error'ed out when I tried it a few weeks ago. The problem then was the silly error window continued way past the bottom of my display and with no scollbar, I could not see the problem. So I ignored it and moved on to better things.

My thought was, use preview to grab a screenshot and I might see the error. Well, the 1st thing I see is a 'show logs' button. OMFG, been looking for that very thing. A quick display rez change and now I can see the buttons. When you gen bitcode, it's the same thing itunes connect it doing so I figure, same problem.

9_7tznjx6gl2n54ykdf19zhh0000gn/T/MrMCMYxCe5/MrMC.arm64.out"
-= Output =-
duplicate symbol ___hidden#42769_ in:
1223.o
3295.o
duplicate symbol ___hidden#42766_ in:
1223.o
3295.o
duplicate symbol ___hidden#42770_ in:
1223.o
3295.o
ld: 3 duplicate symbols for architecture arm64
Exited with 1

WTF, the normal Linker never barfs at this ? I catch 1223.o and 3295.o on the fly (which is not as easy as it sounds) as Xcode deletes them at the end. A quick nm shows no real info. Where do these come from in a sea of MBs of compiled code. Good old nm shows nothing, grep comes up empty as does strings. Humm, a few hours of picking the scab of depends goes nowhere. I know it has to do with linking and on a hunch I remove a linker flag that is on the todo list to remove, legacy stuff that we really should not require and presto, achive/export/developer with bitcode gen completes. A quick flick into itunes connect and more watching paint dry, then after an hour and 15 mins, ding. Out pops the goodies. Oh happy day

2015.11.25 update:
“iTunes Connect: Your app MrMC has been approved for beta testing”

Time to release the kraken

Welcome to the wonderful world of the App Store... It looks like you've been hitting some hard rocks as the first developer to ever submit tons of legacy XBMC code to Apple's validation tools, so it makes kind of sense that this is so painful.

One question - when you write that MrMC is huge with all the libs, is it huge like in "oh my god I will hit the tvOS 200MB limit" too?

The 200MB limit is a valid concern, but in Apple's infinite wisdom, you can't tell the real size because of the embedded bitcode. The only way to know is when you get poked for exceeding the limit Lots of devs bitching about that already.

But I have several tricks left in my porting toolbox to deal with that issue if it does surface.

Thanks Davilla for an excellent update on your project!
Most of it went straight over my tiny non coding head but at least I understand what you have to deal whit.
Godspeed and may the code be with you in your quest for the righteous way through app stores thorny path

Thanks for all the work you guys are putting into this project! And it's nice to read how much time goes into getting an app into the AppStore (or TestFlight), gives people an idea of all the things you're going through to make this all work

I'm very glad that y'all still pushin' on even with all these road blocks y'all havin' ... many tnx in advance guys keep the faith while the rest keep hope alive

Ergh! Great work overcoming these hurdles. This sort of stuff always happens with app submission.

Also hoping that the testflight beta review goes through.

I am concerned that this could potentially get held up indefinitely in the review process, just because apple is apple.

Assuming you have thoroughly reviewed https://developer.apple.com/app-store/r ... uidelines/ and addons etc are not included.
Points of concern: 2.7, 8.6, 10.3, 10.4

Fingers crossed!

2.7 Apps that download code in any way or form will be rejected.
- no addons, no download of code, check Oh and BTW, this clause is violated by every TVML AppleTV app out there as server side js is downloaded and run by the client side. Blessed by Apple ( they came up with it) and you can even change the server side code without requiring Apple approval. I guess javascript is not considered 'code' to Apple

8.6 Apps that include the ability to download music or video content from third party sources (e.g. YouTube, SoundCloud, Vimeo, etc) without explicit authorization from those sources will be rejected.
- no addons, so no access to third party sources, check

10.3 Apps that do not use system provided items, such as buttons and icons, correctly and as described in the Apple iOS Human Interface Guidelines may be rejected.
- humm, I think 'may' is the key word here. But we do use the system keyboard

10.6 Apple and our customers place a high value on simple, refined, creative, well thought through interfaces. They take more work but are worth it. Apple sets a high bar. If your user interface is complex or less than very good, it may be rejected
- Yea, like Skype is a simple, well thought out interface we could always change the skin to something else. Just have to see what they say.

@davilla

I m sure you are doing a great job and I hope that all your efforts will bring you and the community great results but I m starting getting confused on that MrMC will be able to do, if we compare it to Kodi.

I have been reading different comments, in this forum and other, but I must have missed something because your last comments took me by surprise...
If I cannot install any addon, not even the ones included in the official Kodi repo,... the only thing that it comes in my mind it is only playing files either from local directory (I mean a space dedicated from the apple tv internal memory) or from a source part of my local network or if I m lucky from a dedicated server...

Maybe it is not necessary, but since you have been so open to describe the step of project, it could be very interesting for the community to understand where we stand with the "What MrMC can do" too

What do you think?

MrMC is a fork/rebrand/refactor and sanitizing of XBMC/Kodi codebase. That codebase is close to unmaintainable and there is so much legacy cruft inside that refactoring to resolve serious core issues is very, very difficult. That's why MrMC is taking the cutting knife to it and chopping out parts right and left. What you see in the existing public github repo (https://github.com/MrMC/mrmc) is only a hint of where we are right now.

Yes, python is gone, so everything that depends on it, addons, scripts, etc are also gone. Python support has always been a hack, there are constant issues with it and threads and it has become a nightmare to deal with in the codebase. It took me months to get python building as a dependent lib long, long ago when I did the XBMC for ATV2 port and ever since it has been a pain in the rear to deal with. Arm64 is going to be a major hassle for kodi devs to deal with.

Personally, I'm glad to see python go, as the existing Kodi python/addons structure has become a haven for pirates and parasites looking to make quick profits with little effort. So much that rebranding of XBMC to Kodi has retained the tarnish. Amazon bounced Koid out of their store for that very reason.

There IS a rough plan to resurrect addons using javascript but that will take some time to implement. Javascript exists native on all the platform we plan to support AND is blessed by Apple too.

Other things are also gone, screensaver, visualizers and more. These things might return in a later version but they just had to get nuked for now. These choices were not easy ones, believe me. Our main guide was, if the function/feature was already present in TVOS, nuke it.

For version 1.0, the aim is native (no transcode), stable local server/file playback and MrMC in the Apple App Store for iOS/TVOS. If you want to run some addon to fetch remote content, then MrMC is not for you. Wait for Kodi devs to pick up our changes and sideload.

Version 1.0 is just the start. Regardless of Apple App Store popularity, we are here for the long term and the plan is to continue to refactor the codebase to fix core issues and add/restore features.