[mythtv-users] A little help clarifying dummy tuners and HD ringbuffers

Cody Hofstetter codyhofstetter at gmail.com
Thu Aug 6 22:10:35 UTC 2015


Hello all!

Still trying to fix a LiveTV "error opening jump program file buffer" when
switching programs and am hoping for a little clarification on dummy tuners
and HD ringbuffers.

I'm using Mythbuntu 14.04 and .27 with a HDHomeRun Prime in CableCard mode.

First, my searching through the forums/archives has led me to find that
dummy tuners were originally designed for use as a development tool for
those without the hardware wishing to contribute to Myth (e.g. on a laptop,
no tuner card, etc) and for use on backends with no tuners.

I've come across some errors indicating dummy tuners (I believe) that I was
unaware were set up. Which lead me to wonder if MythTV automatically sets
up dummy tuners and if so, why?

E CoreContext fileringbuffer.cpp:300 (OpenFile)
FileRingBuf(/var/lib/mythtv/livetv/1043_20150805170925.mpg): OpenFile():
File too small (0B).
E CoreContext mythplayer.cpp:2718 (JumpToProgram) Player(1):
JumpToProgram's OpenFile failed (card type: HDHOMERUN).
E CoreContext mythplayer.cpp:2719 (JumpToProgram) LiveTVChain has 6
entries#012 DUMMY: 1026 (17:08:58 to 17:08:58)#012 HDHOMERUN: 1026
(17:08:59 to 17:09:06) discontinuous#012 DUMMY: 1028 (17:09:06 to 17:09:07)
discontinuous#012 HDHOMERUN: 1028 (17:09:07 to 17:09:24)
discontinuous#012 DUMMY: 1043 (17:09:24 to 17:09:24)
discontinuous#012* HDHOMERUN: 1043 (17:09:25 to 18:30:00) discontinuous
E CoreContext mythplayer.cpp:2960 (EventLoop) Player(1):
Unknown recorder error, exiting decoder

The MythWiki "Dummy Tuner" page says it's been outdated since .24 and Myth
now has a dedicated "demo tuner". Hence the wondering if they automagically
setup or I'm getting this error because of the Prime tuner.


Second, I understand the HD ringbuffers are, to paraphrase " to weather
moments of stress and too large a ringbuffer will result in swapping"
(description used in backend). So my question after searching through
everything is, let's say most modern systems have at least 2/4gb of memory.
Even if the swappiness is set to 60 as the default for most Linux distros,
you still have plenty you could add before running into a problem (since
the default is 9600kb). Please correct me if I'm wrong, but increasing the
ringbuffer size won't increase the amount of time between switching
programs in LiveTV (it should actually decrease it if switching for example
from channel 2 to channel 3 and then back to channel 2?). From one of the
many many posts I read somewhere I got that the live-tv chain ID is sent
from the frontend to the backend and this is when the ringbuffer is
assigned. Then the frontend loads the first channel in the chain to the
ringbuffer. When the program guide data is changed (when you switch
channels), it automatically creates a new file/chain entry. Is the only
possible issue that would result from setting the ringbuffer higher is that
it could get swapped?

With the "RingBuf: Taking too long to be allowed to read.." error, where
would you increase the timing to allow it to wait longer?  Unless I'm
completely off and that's not the way you solve this error.

*http://pastebin.com/rWvzir9s <http://pastebin.com/rWvzir9s> ---
Backend/Frontend Logs*

If anyone could even give me a partial answer it would help so frigging
much! It's a nightmare trying to troubleshoot things after spending hours
searching and still not finding a simple answer as I'm sure everyone can
attest to. You guys are immensely helpful when stuck!

Thanks again!

P.S. Gary already helped me solve one previous error and I find the
troubleshooting guide with the errors section of the MythWiki easiest to
understand when looking for a particular error. I know there has been talk
of restructuring the wiki and I would like to put the errors I have as I
solve them in the troubleshooting guide to help anyone else who has the
same issue. I wouldn't mind lending a hand in helping reorganize the wiki
either if someone has taken a lead and can point me who to talk to.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20150806/35933a17/attachment-0001.html>


More information about the mythtv-users mailing list