Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#9794 closed Bug Report - General (Fixed)

Remote frontend temporarily pausing during playback of recorded or live tv

Reported by: lists@… Owned by:
Priority: blocker Milestone:
Component: MythTV - General Version: 0.24-fixes
Severity: medium Keywords:
Cc: Ticket locked: no

Description

I'm having a problem with playback of recorded material on a remote frontend in 0.24-fixes. Playback hangs momentarily during start/stop of recordings on the backend, during a reschedule on the backend, or during expiration of recordings from the backend.

I've gone through my configuration to try and debug this problem and consider there must be some kind of problem with locking in the backend code which I cannot work around.

I noticed that there was a peak in hard drive access on the backend during a pause and a bit of digging showed that mysql was creating a temporary table on disk, so I put the temp dir for mysql on a ramdisk and this shortened the length of the pauses. It seems to me that the backend is locking on the result of a database query which starves the frontend of data.

I tried tuning mysql using mysqltuner.pl and things got much better, but the pauses (which are much shorter now) still occur.

I've also tried mounting the recording directory via nfs (using nfs-kernel-server) but this hasn't improved the situation.

I can play back local or network mounted HD files (big buck bunny) on the frontend with other software using vdpau and have no issues. There were no issues with this hardware for versions of mythtv prior to upgrading to 0.24-fixes.

The load on the backend is low with little other software running. Stressing up this machine via dd or other operations does not cause a pause on the frontend.

Reception gives a 100% lock when viewing live tv in the frontend, and recordings play back fine on other systems.

My config:

  • 2 x HD Homerun DVB-T (multirec, 4 tuners per physical = 16 in total)
  • As I'm in Australia, DVB-T broadcasts MPEG2
  • I transcode to H264 via a custom transcoding job with a locally built ffmpeg.
  • Gigabit network

Whitebox backend (Ubuntu 10.04) with:

  • Xeon CPU 3040 @ 1.86GHz
  • 4G ram, 92 kb of swap used after weeks of running
  • xfs recording filesystem on hardware raid 1
  • ext3 filesystem on a separate hardware raid 1 for the database
  • Hardware raid can easily sustain 50 MB/s sustained read and writes with other activity happening on the machine.

ION frontend (Mythbuntu 11.04) with:

  • nothing fancy, just a 250G sata drive
  • vga output to component feed in to old crt widescreen hdtv (720p) via a converter box (audio-authority unit)

I've tried pretty much all the debugging I can, but can't seem to solve the problem. If there is any other information I can provide, please let me know.

Backend Version (frontend running the same version from the mythbuntu daily build repository):

Please attach all output as a file in bug reports. MythTV Version : v0.24-287-g8dd67eb MythTV Branch : fixes/0.24 Network Protocol : 63 Library API : 0.24.20110505-1 QT Version : 4.6.2 Options compiled in:

linux debug using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_directfb using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtdbus using_qtwebkit using_v4l using_v4l2 using_x11 using_xrandr using_xv using_bindings_perl using_bindings_python using_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

Note: This is my first bug report, so I'm not sure I've done this all correctly. I have searched the list of tickets already and didn't find any that were duplicates of this one.

Change History (9)

comment:1 Changed 8 years ago by Patrick Nichols <lists@…>

Oops, I've just been checking the details and the database is on an ext4 filesystem (not ext3).

comment:2 Changed 8 years ago by tralph

Milestone: unknown0.25
Priority: minorblocker

comment:3 Changed 8 years ago by Patrick Nichols <lists@…>

This problem seems to have been solved somehow during yesterday's fiddling with mythtv. I did the following things, but I'm not sure which one would have had an effect.

  1. Upgraded to a new build of 0.24-fixes.
  2. Updated the theme via the frontend menus to blue-abstract 1.4.
  3. Added channel icons for all of my channels.
  4. Enable "Master Backend Override" in mythtv-setup
  5. Reduced the "HD Ringbuffer size" to 9700 kb in mythtv-setup.
  6. Upgraded the firmware of my HDHomeruns to version 20110323.

I'm currently running the following version and started 13 concurrent recordings while transcoding was happening with no ill effects.

pat@lamb:~$ mythfrontend --version Please attach all output as a file in bug reports. MythTV Version : v0.24.1-36-gd06878a MythTV Branch : fixes/0.24 Network Protocol : 63 Library API : 0.24.20110505-1 QT Version : 4.7.2 Options compiled in:

linux debug using_alsa using_oss using_pulse using_pulseoutput using_backend using_bindings_perl using_bindings_python using_dvb using_firewire using_frontend using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_lirc 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_mythtranscode using_opengl using_vdpau using_ffmpeg_threads using_live using_mheg

comment:4 Changed 8 years ago by markk

Patrick - can you try and back out some of those changes (one at a time) to see if you can isolate anything that obviously helps? I appreciate some may be hard to reverse (e.g. reverting to an older build, older HDHR firmware) - but any pointers would be much appreciated.

thanks and regards

Mark

comment:5 Changed 8 years ago by Patrick Nichols <lists@…>

I've backed out individually and in combination all changes except 1 & 6. These did not have any effect on pausing (or lack thereof at the moment). I'll see if I can chase down the old HDHomerun firmware first before trying to find an old build of myth. I'm not sure that I'll be able to back out change 1 unless I restore from backups - something I'm not keen to do.

Summary - none of the following have any effect.

  1. Updated the theme via the frontend menus to blue-abstract 1.4.
  2. Added channel icons for all of my channels.
  3. Enable "Master Backend Override" in mythtv-setup
  4. Reduced the "HD Ringbuffer size" to 9700 kb in mythtv-setup.

To test still.

  1. Upgraded to a new build of 0.24-fixes.
  2. Upgraded the firmware of my HDHomeruns to version 20110323.

Thanks, Patrick.

comment:6 Changed 8 years ago by Patrick Nichols <lists@…>

I've just downgraded the firmware on a HDHomerun with no effect on the lack of pauses. There is only one thing from the list of changes which I have not tested and that downgrading the version of 0.24-fixes.

The version change which resolved the issue for me was:

  • mythfrontend version: fixes/0.24 [v0.24.1-15-gda58b1d]
  • mythfrontend version: fixes/0.24 [v0.24.1-36-gd06878a]
  • mythbackend version: fixes/0.24 [v0.24.1-15-gda58b1d]
  • mythbackend version: fixes/0.24 [v0.24.1-36-gd06878a]

As I mentioned before the frontend is running mythbuntu auto builds for 11.04, and the backend mythbuntu auto builds for 10.04.

Hope this helps, I'm now going to dig around and see if I can downgrade mythtv or restore from backup.

comment:7 Changed 8 years ago by Patrick Nichols <lists@…>

And as a followup I've just looked at the commits between these two versions (0.24.1+fixes.20110618.da58b1d & 0.24.1+fixes.20110629.d06878a) and the only likely one is:

https://github.com/MythTV/mythtv/commit/ef3922514267e53c774ecaeda52d2aa071a1ecf2

I haven't had much luck in finding the older packages to downgrade without compiling them myself, but I'll bet this is the source of my pauses.

Could you please let me know if you want me to keep digging on this one?

Thanks, Patrick.

comment:8 Changed 8 years ago by markk

Milestone: 0.250.24.2
Resolution: Fixed
Status: newclosed

Patrick - thanks for digging and feeding back. I don't think there is any need for additional information - the commit you've highlighted addressed a known issue and it's good to know it has worked as intended.

comment:9 Changed 8 years ago by stuartm

Milestone: 0.24.2

Milestone 0.24.2 deleted

Note: See TracTickets for help on using tickets.