Stream shuts down after zapping around

[s0faking]

When i zap trough the channels, sometimes robotv stops working (robotv 0.6.0). I only see the loading icon when switching channels after this happens. the only way to make livetv work again is to reboot my shield tv. i have appended a logfile. let me know if you need anything else to solve/identify this issue

switch-channel-vdr.txt shield-channel-switch.txt

[pipelka]

If possible please recheck with the latest git "master" (vdr plugin and TV client). Some really serious issues have been fixed there.

[hoppel118]

Yes, I also saw some sporadic freezes which ended up in rebooting my shield tv. With the latest versions from github for the plugin and the app this seems to be solved for the moment.

Thank you very much! Greetings Hoppel

[hoppel118]

While checking some other things with audio pass through, I saw that issue again. So it's not solved. Sorry!

[pipelka]

@s0faking Is this also still an issue for you ?

[s0faking]

sorry for the late reply. i've been using the latest commit (243496e) for a few days now. in that time to problem has occurred three times, which is much better than it was before, but still not perfect. Especially because only reboots can fix the issue for me.

[pipelka]

Ok. Just a few questions to narrow down the problem:

You need to reboot the android client ? Does restarting the VDR server fix it (without restarting the client) ? Switching to a different channel on the client really doesn't work (when the problem occurs) ? Are you watching encrypted channels (any active CAM slots on the VDR server) ? Could you please try to disable timeshift and check if it happens again ?

[s0faking]

You need to reboot the android client ?

i have to reboot my shield tv to fix the problem. also tried killing robotv and restarting it but that didn't work

Does restarting the VDR server fix it (without restarting the client) ?

havent tried that yet. will do when the problem occurs next time

Switching to a different channel on the client really doesn't work (when the problem occurs) ?

nope. its possible to switch through the channels but i only see an infinite loading icon, no matter what i do

Are you watching encrypted channels (any active CAM slots on the VDR server) ?

yes i do. i'm running a orf card on my server(oscam,smargo,vdr-sc). but the problem also occurs with FTA channels, so i'm not sure if there is a connection

Could you please try to disable timeshift and check if it happens again ?

timeshift is already disabled

does the problem occur with your setup? i think you are using the same hardware as i do, right? to me it kind of looks like the mediaencoder from my shieldtv breaks, when doing excessive zapping. sometimes i cant play videos from youtube or kodi after running into the issue. i will try to collect some logs of that too

[my setup]

Client: ShieldTV Robotv (243496e)

Server: HP ProLiant MicroServer Gen8 Ubuntu 16.04.1LTS VDR 2.2.0-5build1 vdr-plugin-robotv (9a923fc) vdr-plugin-sc tbs 6981 dvb-s2 twin tuner smargo(ORF Card) -> oscam

[pipelka]

I never had to reboot the Shield Console (even not my Nexus Player) if a channels doesn't start.

I see non-starting channels very very rarely but it's caused by a bug in VDR (in this case, restarting VDR fixes the problem). See here: http://www.vdr-portal.de/board17-developer/board97-vdr-core/128920-ring-buffer-overflows-cdevice-detach-blockiert/index5.html

I identified a second occasion when this happens: The stream is started on the server but the "stream change" notficiation will not be sent. I didn't figure out completely why this happens but seems to be related to dvbapi/oscam (unable to decrypt channel for some reason). In this case you simply can switch to a different channel.

The problem here is that I'm unable to repoduce the situation where I have to reboot the Shield TV. Is there any error notification when this happens ?

I'm using pretty much the same setup but I'm using vdr-plugin-dvbapi from manio.

[pipelka]

One more thing. Are you using AC3 passthrough ? Maybe AC3 passthrough is causing this. On my production system I'm not using AC3 passthrough.

[s0faking]

One more thing. Are you using AC3 passthrough ?

nope, i deactivated the passthrough because the CEC thingy doesnt work on my AV Receiver, at least not very stable ;)

I see non-starting channels very very rarely but it's caused by a bug in VDR (in this case, restarting VDR fixes the problem). See here: http://www.vdr-portal.de/board17-developer/board97-vdr-core/128920-ring-buffer-overflows-cdevice-detach-blockiert/index5.html

i saw that problem on our Office VDR which is running a UPC Card and streamdev server. on my dvb-s2 system i've never seens that error.

I identified a second occasion when this happens: The stream is started on the server but the "stream change" notficiation will not be sent. I didn't figure out completely why this happens but seems to be related to dvbapi/oscam (unable to decrypt channel for some reason). In this case you simply can switch to a different channel.

unfortunately that doesnt work for me. channel switching results in the infinite loading icon, no matter what channel i switch to

The problem here is that I'm unable to repoduce the situation where I have to reboot the Shield TV. Is there any error notification when this happens ?

to be honest i was also rarely able to reproduce this issue, but my girlfriend seems to be have those expert debugger skills ;) she runs into this problem quite often(at least before i was using 243496e). with the new version she was the one who reproduced the 3 breakdowns i mentioned before :)

[pipelka]

I also have such an expert debugger at my home (+ 2 apprentices) ;-) Maybe you should exactly watch her changing channels (I learned a lot how to change channels from my wife). Maybe there is a pattern how to reproduce this.

[s0faking]

hehe, will do

[s0faking]

i was just able to reproduce the issue again. tried to restart the vdr, but that didn't work. i also tried the youtube app after the problem occured but this time it played videos just fine so i guess you can forget the thing i said a few posts ago about the mediaencoder breakdown.

idle-video.txt

[pipelka]

Back in business, ... Please check if the "stream-fix" branch of the VDR plugin makes any difference for you: https://github.com/pipelka/vdr-plugin-robotv/tree/stream-fix

Switching times will be a bit longer, but it hopefully fixes the issue.

[s0faking]

awesome. thx. just built the stream-fix branch. will report back if s*** goes down ;)

[s0faking]

unfortunately the stream-fix branch doesnt fix the issue. still no clue whats causing this :(

shield.txt vdr.txt

[pipelka]

I'm also a bit clueless, ... I recently fixed some ExoPlayer related issues. Maybe you want to recheck with the current "master" versions of the client and the vdr plugin.

[pipelka]

After analyzing your logs I was able to reproduce this issue with the following procedure:

• make sure roboTV is stopped
• open Live Channels
• slightly just before playback starts switch to a different channel

I think this triggers a deadlock in the messaging layer. I created the "deadlock-fix" branch to take another attempt on fixing this: https://github.com/pipelka/roboTV/tree/deadlock-fix

[s0faking]

awesome. thx @pipelka. u rock. will try this right away

[pipelka]

I know I'm a bit impatient but are there any news on this ?

[tunip]

The fix is in master branch? I try to reproduce the issue.

[pipelka]

Yes. It's already in master. Thanks

[s0faking]

sorry @pipelka. hadn't had the time to test. my girlfriend told me it happened again, but i wasn't able to collect logs because i wasnt home.

[tunip]

Latest roboTV and vdr-plugin-robotv with channel cache disabled, I am not able to reproduce the issue.

[s0faking]

i was able to test the deadlock-fix branch. unfortunately it happened again. still not sure how to reproduce. shield.txt

[pipelka]

Thanks for the log. The issue is still the same. I seems message handling (even in ExoPlayer) dead-locks somehow. I'll prepare a new test branch addressing more maybe-dead-locks.

[pipelka]

I updated (rebased) the "deadlock-fix" branch. So please re-pull. I moved all message handling into the main thread. Let's see what happens.

[pipelka]

Please also update the vdr plugin to the latest "master".

[s0faking]

you're the best. will get back to you after testing. cheers

[pipelka]

Eventually I will believe being the best when this bug gets finally fixed 😎 Thanks for testing

[s0faking]

the problem hasn't occured since my last update. so i guess its official now. you are the best ;) thx @pipelka

[pipelka]

Great news. The fixes from the "deadlock-fix" branch were merged into "master". I'll leave this issue open for a while just to be sure, ...

@hoppel118 Could you please be so kind and double-check if this issue is also fixed for you ?

[pipelka]

I see, ...