4np / UitzendingGemist

An *Unofficial* Uitzending Gemist application for Apple TV 4 (**deprecated, use TV Gemist ☝🏻**)
Apache License 2.0
49 stars 8 forks source link

Trouble playing episodes on limited bandwidth connections #21

Closed TookiTheGreat closed 7 years ago

TookiTheGreat commented 7 years ago

I am trying to get the new version to run but it terminates in an uncaught exception error. As far as I know I haven't changed anything since the last time I successfully built a version. I tried as targets both 10.1 and 10.0, with the same results. My appleTV runs 10.1. This is the debug output:


2017-03-15 17:12:32:913 UitzendingGemist[210:12926] No update available (current: 1.4.1, latest: 1.4.1) uncaught exception in notifier thread: N5realm10LogicErrorE: Bad version number 2017-03-15 17:21:32:487 UitzendingGemist[210:12926] Player is now waiting to play at the specified rate libc++abi.dylib: terminating with uncaught exception of type NSException (lldb)


The first exception doesn't stop the app from continuing, the libc++abi.dylib error does. This is the code shown when the error occurs, with the "super.observeValue" line highlighted:


override func observeValue(forKeyPath keyPath: String?, of object: Any?, change: [NSKeyValueChangeKey : Any]?, context: UnsafeMutableRawPointer?) {
    guard context == &observerContext, let item = player?.currentItem else {
        super.observeValue(forKeyPath: keyPath, of: object, change: change, context: context)
        return
    }

4np commented 7 years ago

Could you please perform the following steps:

  1. completely remove the Uitzending Gemist app from your Apple TV (this will also remove your favourites, but it should fix that N5realm10LogicErrorE: Bad version number)
  2. remove the build cache by pressing command-option-shift-k in Xcode and press the clean button in the modal dialog that will show.
  3. try to again build and deploy to your apple tv
TookiTheGreat commented 7 years ago

Did all of the above. It did get rid of the N5realm10LogicErrorE error, but still terminates with this:

2017-03-16 13:11:58:615 UitzendingGemist[199:7912] No update available (current: 1.4.1, latest: 1.4.1)
2017-03-16 13:22:57:023 UitzendingGemist[199:7912] Player is now waiting to play at the specified rate
libc++abi.dylib: terminating with uncaught exception of type NSException

The interesting thing is that it now runs fine in the emulator but not on the AppleTV itself. They are both using the same network, same firewall, same router, ... If the urishield validator you spotted in the URL, where could that come from, and why would it cause a fault in the AppleTV and not in the emulator? I'm asking, because I hope to find out what is happening, not because I expect you to fix it. You've done so much already, and I can't expect you take responsibility for one crazy configuration running on flakey Australian Internet.

4np commented 7 years ago

The exception you see is caused by the Key-Value Observing I added in the previous release to debug the state of the video player. While the exception you are getting should not happen (and hence I am not sure why you are getting it), I have made debugging configurable and disabled it by default. This means you should not see that exception anymore (as the code causing it is disabled by default), but that also means you will not see any debug information regarding the state of the video player.

If you would still like to see the debug messages, you can easily enable it by doing this:

player-debugging

The urishield validator is added by the NPO, probably when they notice you are not in The Netherlands? If you are allowed to see the content, it should work. Note that 1.4.1 now reports and disables the play button for episodes that you will not be able to watch. It might be a coincidence, but it seems like more episodes seem to have the geo check in place as of the past couple of weeks. Perhaps the NPO is being more strict about what you are able to watch abroad and those were actually the episodes that were failing for you?

Geo checks

TookiTheGreat commented 7 years ago

I can still watch everything from the web interface, so what would be NPO's reason to do a different geo-check depending on what app calls the API's? But I will try to run your latest version to see what happens.

TookiTheGreat commented 7 years ago

I meant "everything I would normally watch" - foreign content is usually geo-blocked, as are some series that are co-produced with other countries. Most Dutch content seems unblocked.

TookiTheGreat commented 7 years ago

Well I tried running the new version with debugging off and on. Turning debugging off does stop the exception, but I can't get the episodes to play on my AppleTV. They do play on the simulator, sometimes after the second attempt, but just time out on the device. Live streams work fine.

I'm giving up for now and returning to playing them through the web interface and Airplay, which is a bit clunky but will have to suffice.

Thanks for all the great work. Maybe proper Internet will arrive in Australia and I can join the civilized world.

4np commented 7 years ago

I find it really strange that they do play in the simulator but not on device, which does not make any sense at all as it is the same thing. It makes me think your firewall plays a role here. What you could do is unplug your Apple TV and change your computer's IP address to that of the Apple TV and see if the simulator is still able to play the videos...

TookiTheGreat commented 7 years ago

Hi Jeroen

That’s a good idea. I will be away (again) for the next three weeks, but when I get back I will embark on some explorations into this strange behavior. Any other ideas you can think of are more than welcome.

4np commented 7 years ago

Hi Bard,

While the live streams are adaptive (and hence will optimise for the available bandwidth), the episode streams were not and were being prioritised by order of quality (from highest to low).

Today I pushed changes that on the one hand add support for an Adaptive stream, and on the other hand allow customisation of the order of video quality preference. By default the order of preference is: Adaptive, Hoog, Normaal, Laag (the latter three in Dutch as the NPO uses these values as well.) This basically means that when an episode stream has an adaptive version available, that stream will be used. If not, it will check if the Hoog quality stream is available, and so forth.

As the episodes now support adaptive streams, I am confident they should now work properly for you. However, if you still experience issues during episode playback you can now configure the order of preference (for example to: Laag,Normaal,Hoog,Adaptive) to forcibly prefer low quality (=bandwidth) streams and see if the episodes will start playing (better)?

videoqualityorderofpreference

If this will make things work better for you I might consider including a normal user friendly settings menu in a later release ;)

TookiTheGreat commented 7 years ago

Hi Jeroen,

Thanks for your continued work on the app. That is much appreciated. I will be on the road till April 10, but as soon as I am back home I will be having a go at this new version. One of the reasons the emulator might work where the AppleTV will not is that the machine I run the emulator on seems to cache downloads locally, which I don't think the AppleTV does. So, on a second attempt to play an episode the emulator doesn't time out and does get to play whatever had been cached before.

Bard

4np commented 7 years ago

Hi Bard,

I just released 1.5.0 which brings several video stream improvements as well as closed captioning support.

Safe travels and I am looking forward to hear if things are working better for you now :)

Jeroen

4np commented 7 years ago

@TookiTheGreat : I have been debug issues another user from Dubai was experiencing (see #22) and the latest code is confirmed working with unlocator. Another thing you might give a shot (they have a 7 day free trial).

TookiTheGreat commented 7 years ago

Hi Jeroen,

I have returned home, installed the new 1.5.0 version and am very happy to report that everything is working fine again! Episodes are a bit grainy at moments (did I tell you how crappy our Internet is here in Australia?) but the resolution usually improves after a few minutes and most episodes then play fine till the end. We only experienced some instances of buffering but nothing too annoying - in fact the app's streaming behavior is now very close to that of Netflix, which is a huge improvement over how previous versions behaved, even when they did manage to get episodes started.

I want to thank you for the great work you are doing with this app. If the NPO had any sense they would buy it off you and make it official, or else pay you a handsome amount to keep developing it under their logo.

4np commented 7 years ago

Hi Bard, that's great news! I was holding off pushing a 1.5.1 release awaiting your feedback. Just to make sure, did you use the 1.5.0 zipfile or did you use the latest code? The latest code is 8 commits ahead of the 1.5.0 release and contains an extra configuration switch to force secure connections (which I will probably remove again).

ps. not too much trouble with the floods down under I hope?

TookiTheGreat commented 7 years ago

I used Saturday’s commit, so most likely with all your latest code included.

4np commented 7 years ago

Fixed in 1.5.1