MythTV Playlist exits prematurely

[Ryan Hadley <ryan.hadley@…>]

When I add a good amount (10+) of videos to a playlist and start it up, it never plays through the entire list. It appears to be random where it exits. I can play the same playlist several times and it will always exit the playlist and return me to the recorded programs menu before it gets to the end of the playlist.

If I add just a few, 2-3 shows, it sometimes plays the whole list. But occasionally will even exit out after the first show is done.

I'm running off head from just last night (4/7/2010).

# mythfrontend --version Please include all output in bug reports. MythTV Version : 23989 MythTV Branch : trunk Network Protocol : 56 Library API : 0.23.20100404-1 QT Version : 4.5.0 Options compiled in:

linux release using_oss using_alsa using_backend using_directfb using_dvb using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

# mythbackend --version Please include all output in bug reports. MythTV Version : 23989 MythTV Branch : trunk Network Protocol : 56 Library API : 0.23.20100404-1 QT Version : 4.5.0 Options compiled in:

linux release using_oss using_alsa using_backend using_directfb using_dvb using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

MythTV configure: ./configure --prefix=/usr/local/mythtv --enable-libfaad --enable-proc-opt --disable-lirc --disable-joystick-menu --enable-vdpau --extra-cflags=-fomit-frame-pointer --extra-cxxflags=-fomit-frame-pointer

[robertm]

Need -v playback frontend logs.

[Ryan Hadley <ryan.hadley@…>]

Added 13 shows to playlist. Played playlist on shuffle mode. It played 2 shows and exited. I grabbed the log immediately after the playlist ended prematurely.

[scooter <mythtv@…>]

I'm not sure if it is frowned upon for this type of "me too" message, but....

If a different system is needed for debugging, I can assist. I'm also experiencing the problem described in this issue. Dedicated backend system and multiple frontends on 0.23.

One frontend and the backend at: MythTV Version : 25141 MythTV Branch : branches/release-0-23-fixes/mythtv/ Network Protocol : 56 Library API : 0.23.201000617-1 QT Version : 4.6.2

And one frontend at: MythTV Version : Unknown MythTV Branch : branches/release-0-23-fixes Network Protocol : 56 Library API : 0.23.20100429-1 (latest minimyth 0.23 release)

Scott

[jra@…]

We're seeing this as well, 0.23.1 from RPM on SuSE 11.3. Initially I thought it might be related to MythTV locating clips in a storage group that it hadn't yet played and caching their locations (we imported our old programs into a fresh install), but we ruled that out. Does the assignee want -v playback logs from us as well?

[matthyo@…]

any news on this? happens to me too in 0.24 and 0.24-fixes, it does appear to be random but I am rarely ever able to play 2 or 3 things in a row, If I remember to hit 'Esc' before the recording ends it will play the next recording like it is suppose to.

I'd really like to set a bunch of stuff to watch rather than always choosing something every 30/60 mins, I've even tried switching over too Xbmc but that just has a whole bunch more bugs.

[stuartm]

This doesn't look that complicated to figure out, I'm willing to bet it's the 100ms timeout on the availability check - when that's reached we clear the whole playlist. 100ms seems far too short if we're having to spin up a drive or similar to check the file is available.

[Github]

Increase kMaxUIWaitTime to 10 seconds. The theory is that this timeout was to prevent a very delayed response to an availability check causing playlists to resume playing long after the user had moved on. The present timeout was very short though and didn't account for delays caused by disks needing to be spun up or just the latency of checking multiple storage groups for a file. Almost certainly fixes #8316

Branch: master Changeset: 6c3a799706eb6f18757f8984819bf5c4c2425659