[mythtv-commits] Ticket #12187: UPnP - Fix broken FFWD/REW/JUMP in playback for LG SmartTV DLNA clients for recordings with startoffset
MythTV
noreply at mythtv.org
Wed Jun 25 20:12:37 UTC 2014
#12187: UPnP - Fix broken FFWD/REW/JUMP in playback for LG SmartTV DLNA clients for
recordings with startoffset
---------------------------------+-------------------------
Reporter: ludvik.tesar@… | Owner: dblain
Type: Patch - Bug Fix | Status: new
Priority: minor | Milestone: unknown
Component: MythTV - UPnP | Version: Master Head
Severity: medium | Keywords:
Ticket locked: 0 |
---------------------------------+-------------------------
I would like to propose this simple fix that affects some LG SmartTV DLNA
clients. This fixes error in playback navigation through FFWD/REW buttons
and through the navigation bar. The patch replaces dtProgStart by
dtStartTime in the query into recordedmarkup table.
The patch is at : https://github.com/MythTV/mythtv/pull/76
Description of the bug : If the recording is recorded with non-zero
startoffset, the playback navigation in DLNA client is then completely
broken. If you Jump forward (with FFWD button) or jump backward (with RWND
button) or you navigate through the recording using the navigation bar,
the playback jumps to the position that seems not to be related to where
you intended to jump. Sometimes forward jump might go backwards and vice
versa. It is quite frustrating. Consequently, WAF is completely ruined.
Afected clients : LG SmartTV series 2012, probably also other series that
share the same code, 2011 and 2013. Windows Media Player is not affected.
Cause : This behaviour is caused by wrong duration attribute of <res/>
tag, which is calculated from EIT data rather than from the real mpg file
playback duration. This is because playstart is used instead of starttime
in the query to recordedmarkup, so the query fails and as fallback,
record.progend - record.progstart is used as duration. The client expects
the duration value to be precise, otherwise jumping to position is broken.
It is clear that the bug is there since 2006, since the first time UPnP
was added and it is still in master branch. It was probably not so
apparent in past, since not so many clients use the duration attribute for
anything.
I have tested this well with current stable build from mythbuntu :
MythTV Version : v0.27.1-15-g050bf9d
MythTV Branch : fixes/0.27
Network Protocol : 77
Library API : 0.27.20140520-1
QT Version : 4.8.4
Options compiled in:
linux profile use_hidesyms using_alsa using_oss using_pulse
using_pulseoutput using_backend using_bindings_perl using_bindings_python
using_bindings_php using_crystalhd using_dvb using_firewire using_frontend
using_hdhomerun using_ceton using_hdpvr using_ivtv using_joystick_menu
using_libcec using_libcrypto using_libdns_sd using_libfftw3 using_libxml2
using_lirc using_mheg using_opengl using_opengl_video using_qtwebkit
using_qtscript using_qtdbus using_sdl using_taglib using_v4l2 using_x11
using_xrandr using_xv using_profiletype using_bindings_perl
using_bindings_python using_bindings_php using_mythtranscode using_opengl
using_vaapi using_vdpau using_ffmpeg_threads using_mheg using_libass
using_libxml2
--
Ticket URL: <https://code.mythtv.org/trac/ticket/12187>
MythTV <http://www.mythtv.org>
MythTV Media Center
More information about the mythtv-commits
mailing list