[popcornmix]

I am experiencing very similar cases. But even on omx it crashes after some time. The crash or freeze is even faster when not in full screen. Disabling "sync playback to display" has no effect.
Interesting is that on RPi1 if using only Omx player live tv does not crashes but on RPi2 it does.

Can you test an Isengard testbuild from here.
It would be interesting if that doesn't have the same problem.

[maxodolo]

I don't think there is a problem with VDR whatsoever, because with OMX instead of MMAL i have no problems at all. no freezes. everything works. As soon as i try MMAL (and MMAL advanced deinterlacing which i use as default), the problem starts. sometimes within 5 mins sometimes wtihin an hour. happens almost ever on channel switching, rarely when live tv video is running in fullscreen mode. happens on random channels, nothing reproducible.

With omxplayer disabled, can you try disabling "sync playback to display"?

did that for a while now, and it seems more stable (but not perfect) . had two or three "video stops, audio goes on freezes" in about three hours. and with disabled "sync playback to display" i was able to stop the freeze, when pressing "stop". retuning or changing a channel brought video back up.

with enabled "sync playback to display" i wasn't able to stop the video, and had to "systemctl restart kodi" or even do a reboot (ssh was reliably available even during a gui freeze).

Max

[maxodolo]

I am experiencing very similar cases. But even on omx it crashes after some time. The crash or freeze is even faster when not in full screen. Disabling "sync playback to display" has no effect.
Interesting is that on RPi1 if using only Omx player live tv does not crashes but on RPi2 it does.

Can you test an Isengard testbuild from here.
It would be interesting if that doesn't have the same problem.

Does this testbuild include the advanced 1080i deinterlacing?

Max

[illiac4]

I am experiencing very similar cases. But even on omx it crashes after some time. The crash or freeze is even faster when not in full screen. Disabling "sync playback to display" has no effect.
Interesting is that on RPi1 if using only Omx player live tv does not crashes but on RPi2 it does.

Can you test an Isengard testbuild from here.
It would be interesting if that doesn't have the same problem.

I did that few days ago and it has the same problem.

[popcornmix]

Does this testbuild include the advanced 1080i deinterlacing?

No.

[illiac4]

Here is one crash - complete freeze (the same like Milhouse had with my sample):
http://xbmclogs.com/pmyjnfdzs

[popcornmix]

did that for a while now, and it seems more stable (but not perfect) . had two or three "video stops, audio goes on freezes" in about three hours. and with disabled "sync playback to display" i was able to stop the freeze, when pressing "stop". retuning or changing a channel brought video back up.

with enabled "sync playback to display" i wasn't able to stop the video, and had to "systemctl restart kodi" or even do a reboot (ssh was reliably available even during a gui freeze).

Okay, it's worth being clear exactly what the hangs are.
1) Video playback stalls, but OSD works, and you can stop and restart another video
2) Video playback stalls, and it's impossible to stop and restart another video. "systemctl restart kodi" brings back a working kodi.
3) Video playback stall,s and it's impossible to stop and restart another video. "systemctl restart kodi" fails to bring back a working kodi.

If you see (3) then it's definitely a firmware issue.
(1) and (2) are likely kodi issues, with (1) being more trivial.

There are also failures where kodi exits and restarts. These are likely to be bugs in kodi (e.g. a segfault) and we need the crash log for those.

[illiac4]

The funniest thing is that no chrashlogs are created.

[popcornmix]

The funniest thing is that no chrashlogs are created.

Did kodi exit and restart on its own? You should get a crash log for that.
If the screen just stalls, you won't get a crash log.

[maxodolo]

did that for a while now, and it seems more stable (but not perfect) . had two or three "video stops, audio goes on freezes" in about three hours. and with disabled "sync playback to display" i was able to stop the freeze, when pressing "stop". retuning or changing a channel brought video back up.

with enabled "sync playback to display" i wasn't able to stop the video, and had to "systemctl restart kodi" or even do a reboot (ssh was reliably available even during a gui freeze).

Okay, it's worth being clear exactly what the hangs are.
1) Video playback stalls, but OSD works, and you can stop and restart another video
2) Video playback stalls, and it's impossible to stop and restart another video. "systemctl restart kodi" brings back a working kodi.
3) Video playback stall,s and it's impossible to stop and restart another video. "systemctl restart kodi" fails to bring back a working kodi.

If you see (3) then it's definitely a firmware issue.
(1) and (2) are likely kodi issues, with (1) being more trivial.

There are also failures where kodi exits and restarts. These are likely to be bugs in kodi (e.g. a segfault) and we need the crash log for those.

For me it looks like i am getting 1) with disabled "sync video to display"

With enabled "sync video to display" i am getting definitely 3)

Max

[illiac4]

Sometimes it stalles, sometimes it restarts kodi and even then no crashlog is created.

[misa]

For what it's worth, I am running on a Pi2 with the latest Millhouse builds, sd/usb combination and have no issues at all with Live TV or whatever enabled MMAL, overclocked

[MarkT]

I second the crash reports for DVB. #809 vdr-addon, VNSI, FTA or encrypted. Video stalls, audio keeps on playing,
can't tune to a different channel.

My gut feeling is that firmware doesn't handle corrupted MPEG TS/PS well. Which will eventually show up, because
DVB is not 100% good data all the time. Maybe memleak, maybe internal structure corruption.

To prove my hypothesis I propose to record a DVB channel for maybe 2-4 hours and through playback of this file
from disk try to crash the GPU decoder. Can Kodi play TS or PS from file and which container format would be best?
So far I only tested MKV. But I think a test case can be established. If a static file provokes crash, divide file in half,
and try halfes to provoke crash. Divide remains until crash disappears, take last file that provoked the crash.

Also one thing I haven't tried is to disable hardware decode acceleration. I.E. tune to a MPEG2 DVB-channel and let
the ARM decode, not GPU. ffmpeg is a tough cookie, see if the pi crashes now.

[popcornmix]

My gut feeling is that firmware doesn't handle corrupted MPEG TS/PS well. Which will eventually show up, because
DVB is not 100% good data all the time. Maybe memleak, maybe internal structure corruption.

So if you record programs and then play the recording do you get the same failure? (these will presumably have the same corruption from poor signal as watching live tv).
If you do then a sample file would be useful.

[zaphod24]

For what it's worth, I am running on a Pi2 with the latest Millhouse builds, sd/usb combination and have no issues at all with Live TV or whatever enabled MMAL, overclocked

Mostly the same for me here as well, running overclocked with settings I've mentioned previously (arm core at 1050, core at 525, etc), OMX is disabled and MMAL is enabled and both sync options are enabled with resample sound. I am also using advanced deinterlacing for 1080i60. I have very rarely, once a day maybe, ran into an issue that was either #2 or #3. I've never bothered to try just restarting Kodi, but I can try that the next time the issue happens. #1 definitely doesn't work, but I haven't see the issue after updating to 0809 last night. I usually update each day when a new build is available, so it is possible I'm just not running long enough between restarts to see the issue. I do watch a lot of live TV every day though.

About a week ago I added the following to my advancedsettings.xml:

<pvr>
<minvideocachelevel>25</minvideocachelevel>
<minaudiocachelevel>25</minaudiocachelevel>
<cacheindvdplayer>true</cacheindvdplayer>
</pvr>


My PVR backend is MythTV and this appears to force Kodi to wait a few seconds longer and let the cache fill a little more when starting live TV. It could just be a placebo, but scrolling banners on news channels like CNN have been relatively smooth with 0807+ builds and the cache change.