[mythtv-users] 4-digit channel change on a Comcast firewire STB (DCT-6200)

Michael T. Dean mtdean at thirdcontact.com
Tue Mar 20 16:54:24 UTC 2012


On 03/20/2012 12:16 PM, lists.md301 wrote:
> On Tue, Mar 20, 2012 at 11:42 AM, Michael T. Dean wrote:
>> On 03/20/2012 09:00 AM, lists.md301 wrote:
>>> So yes, for anyone searching the archive, 4-digit channel tuning does
>>> work with the Prime, there is just a printf issue in the backend
>>> logging reporting the channel tune number.  I'm assuming the 4-digit
>>> channel changes is still an outstanding issue with various STB's.
>> I'm assuming you reported the location of the logging error so we can
>> just fix it (as that's something we could even do before 0.25 release)?
> No, not yet, both because of my above embarrassment and not getting any
> feedback on the list with guidance on that.  I'd be happy to, though.  Note
> that in both cases below, the channel identified as "5225" should more
> correctly be "51225".  Here' s what I'm seeing in my backend log, tuning to
> BBCAHD on channel 1225, with just the default general,important options:
>
...
> 2012-03-19 19:33:12.539 Finished recording Top Gear: channel 5225
...
> 2012-03-19 19:33:12.606 Finished recording Top Gear: channel 5225
...
> 2012-03-19 19:34:02.495 Finished recording Top Gear: channel 5225

That's not actually meant to be the channel number.  It's the "channel 
ID", which is an internal unique identifier for the channel.  The only 
"bug" here is that we're showing you internal data that you shouldn't be 
concerned about (kind of like how we show card IDs on backend status 
page).  It's something we'll eventually fix, but it will be a while.

That said, I'm assuming that your log files actually show the command 
line when logging information about calling the channel change script.  
If not, you probably just need to add an appropriate -v option (like -v 
system or -v channel).

> Looking further (because of your request), from the (remote) frontend log
> of this LiveTV session, I notice that the naming of the ringbuffer mpeg
> file name is also incorrect, so the issue goes deeper than logging.  This
> may make a "fix" more complicated (since it's not just a logging issue),
> but I'll leave it to the developers to decide:
>
...
> 2012-03-19 19:34:19.710 RingBuf(myth://
> 192.168.1.253:6543/5225_20120319193419.mpg) Warning: Not starting read
> ahead thread, already running
...
> 2012-03-19 19:34:20.433 RingBuf(myth://
> 192.168.1.253:6543/5225_20120319193419.mpg): Waited 0.2 seconds for data to
> become available... 28108<  32768

And, for filenames, they will always be <chanid>_<starttime>.<ext> , so, 
again, that's not a channel number.  We actually can't use channel 
number, here, because dong so would mean we could have 2 different 
recordings that need to use the same file name (because any number of 
channels may be given the same channel number).

> If you'd like me to repeat this with more detailed logging and/or open a
> ticket, I'm certainly willing.  It would be my first, but I'll figure it
> out.

Thanks for looking into it.  For now, no need for a ticket.

Mike


More information about the mythtv-users mailing list