8300HD Firewire works in linux but not in Myth

[Marten]

Basically, I'm unable to get MythTV to use my FireWire-equipped cable box as an input. I'm pretty confident that the problem is not with Linux, nor with the cable box itself, but rather with MythTV. This is because everything works fine outside of MythTV. (Note: Running Mythbuntu 9.04, which uses the latest patched version 0.21 of MythTV).

The cable box is a Scientific Atlanta 8300HD (cable provided by Cox in Las Vegas). I have verified that the majority of the channels are unencrypted. In fact, using the test-mpeg program, I can easily and reliably capture MPEG-2 streams off of the box and straight to files, and they play perfectly.

In MythTV, the channel changing works perfectly (as I change channels, I can watch the channel numbers change on the box itself). However, the only information in the overlay is as follows:

[quote]
Signal 100% | (L__) Partial Lock
[/quote]

After the prescribed delay, the warning box will pop up complaining that "You should have gotten a channel lock by now..."

At the same time, mythbackend.log reports:

[quote]
Preview Error: Previewer file '/home/mythtv/rtemp/11070090417201123.mpg' is not valid.
Preview Error: Run() file not local: '/home/mythtv/rtemp/11070090417201123.mpg'
Preview Error: Preview process not ok. fileinfo(/home/mythtv/rtemp/11070090417201123.mpg.png) exists: 0 readable: 0 size: 0
Of course, I have verified that the channels are unencrypted and can be captured from the command line with test-mpeg. I have also verified that the myth user has read/write access to the recording directory (in this case, I've moved it to the myth user's home dir).
[/quote]

Just to spice things up, in a few instances (less than 0.5%), somehow, MythTV will get a lock and start playing the channel! I've found no way to reproduce this reliably.

I've tried all manner of combinations with the backend settings, including varying the signal delays, bitrates, and trying different drivers. The results appear to be the same, so long as I use 'Generic' or one of the 'Scientific Atlanta' drivers. If I use Motorola drivers, the channel changing ceases to function.

My suspicion is that the problem lies with complexities with the Myth firewire import driver. As I've said, copying via the simple test-mpeg script works flawlessly, every time.

If this is not a bug, any help would be appreciated.

[Mitchell (mitchell-gore)]

I am also effected by this bug. For me thos my 8300 would not change channels with the internet changer. although the script posted here will: http://ubuntuforums.org/showthread.php?t=712789

I have the same issue with test-mpeg2 working 100% of the time but not myth.

Is this a upstream issue or a Ubuntu issues?

Thanks,
Mitchell

[MarcRandolph (mrand)]

As I understand it, there are two problems here:

1. Channel changer may need updating
2. Even with an updated channel changer, video doesn't work reliably

Semi-Related discussions regarding this channel changer (item #1):

http://www.gossamer-threads.com/lists/mythtv/users/385208
http://www.gossamer-threads.com/lists/mythtv/users/355582
http://www.gossamer-threads.com/lists/mythtv/users/355362

[Mitchell (mitchell-gore)]

Correct. The seme-related posts are all for the SA4250HDC box. Which is stated as not working in Myth. I used to have that box with a diff carrier and was able to record with it but not change channels.

The channel changer pry just needs the vendor ID's added for the STB. Thats what I did to the above mentioned script. Attached is the file with My ID's.

The firewire recording issue is where the bigger problem lies IMHO.

Mitchell

[MarcRandolph (mrand)]

Howdy Marten/Mitchell/eblanchette and any others with the 8300,

Upstream has completely turned their focus to trunk as they focus on their upcoming 0.22 release. They just fixed the 8300 cable box identification issue in revision 22045 on trunk (soon to be 0.22) but I do not expect they will be backporting that to 0.21.

As for the video from the 8300 not working, if someone with this problem can run mythbackend with -v important,channel,record it might capture something. We can *try* submitting a 0.21 log upstream, however it is quite possible they not accept it (and instead request the problem be duplicated on 0.22 with those log options). Obviously if we could just start with a 0.22 log capture, that would be preferable.

Marking as incomplete until we have some logs.

[Mitchell (mitchell-gore)]

Finally looks like my patch with vendor ID's was committed!

Marc, I am running weekly builds, currently 21965. Should i wait until I am running atleast 22045 before testing? Can you contact the person that is in charge of builds and see if they can do a rebuild?

I am not really interested in .21 as .22 looks really close. But it would be nice to be able to record everything off firewire. On prior testing with dvbsnoop someone said it looked like it was not finding the program table (PMT). But i have no idea what that really means.

Thanks,
Mitchell

[MarcRandolph (mrand)]

Yep - thank you for the patch, Mitchell!

I don't have a good feel for how this patch might impact the video problem. If myth was not recognizing the cable box, then I don't see how it would have ever worked at all for Marten. So my guess is that this patch won't help the video problem - but as I said, I don't know for sure. My preference would be that if it doesn't work right now, wait until this patch is applied just so we rule that out. If you would like the patch sooner than a few days from now when the main Karmic package is updated, you can switch to the nightly builds (see http://www.mythbuntu.org/auto-builds). They are at trunk22052 today.

[Mitchell (mitchell-gore)]

Ok, here is your log. Mythtv exibits the same behavior. test-mpeg works fine but not mythtv.

2009-09-27 14:07:49.550 scheduler: Scheduled items: Scheduled 289 items in 1.6 = 0.00 match + 1.62 place
2009-09-27 14:07:49.559 TVRec(6): RecordPending on inputid 7
2009-09-27 14:07:49.560 TVRec(6): StartRecording(NFL Football)
2009-09-27 14:07:49.560 TVRec(6): ASK_RECORDING 6 0 0 0
2009-09-27 14:07:49.643 adding: mythtv as a client (events: 1)
2009-09-27 14:07:49.732 TVRec(6): StartedRecording(0x93bd2c8) fn(/tv/d3/1811_20090927140800.mpg)
2009-09-27 14:07:49.732 TVRec(6): ClearFlags(CancelNextRecording,) -> RunMainLoop,
2009-09-27 14:07:49.732 TVRec(6): Changing from None to Watching RecordingOnly
2009-09-27 14:07:49.732 TVRec(6): ClearFlags(FrontendReady,CancelNextRecording,) -> RunMainLoop,
2009-09-27 14:07:49.732 TVRec(6): Request: Program(yes) channel() input() flags(Recording,)
2009-09-27 14:07:49.733 TVRec(6): HW Tuner: 6->6
2009-09-27 14:07:49.734 TVRec(6): ClearFlags(PENDINGACTIONS,) -> RunMainLoop,
2009-09-27 14:07:49.734 TVRec(6): No recorder yet, calling TuningFrequency
2009-09-27 14:07:49.734 FireChan(0022CECC76B00000): Open()
2009-09-27 14:07:49.736 FireChan(0022CECC76B00000): SetChannelByString(3)
2009-09-27 14:07:49.738 SetChannelByNumber(81)
2009-09-27 14:07:49.738 FireDev(0022CECC76B00000): Requesting STB Power State
2009-09-27 14:07:49.740 FireDev(0022CECC76B00000): STB Power State: On
2009-09-27 14:07:49.740 SetChannel(model GENERIC, alt 0, chan 81)
2009-09-27 14:07:49.741 SetChannel() -- locked
2009-09-27 14:07:49.745 SetLastChannel(81): cleared: yes
2009-09-27 14:07:49.745 FireChan(0022CECC76B00000): SetChannelByString(3) success
2009-09-27 14:07:49.745 TVRec(6): Starting Signal Monitor
2009-09-27 14:07:49.745 TVRec(6): SetupSignalMonitor(1, 0)
2009-09-27 14:07:49.745 FireChan(0022CECC76B00000): Open()
2009-09-27 14:07:49.745 FireSM(0022CECC76B00000): ctor
2009-09-27 14:07:49.745 SM(0022CECC76B00000)::AddFlags: Seen() Match() Wait(Sig,)
2009-09-27 14:07:49.746 FireDev(0022CECC76B00000): Requesting STB Power State
2009-09-27 14:07:49.748 FireDev(0022CECC76B00000): STB Power State: On
2009-09-27 14:07:49.748 TVRec(6): Signal monitor successfully created
2009-09-27 14:07:49.748 TVRec(6): Setting up table monitoring.
2009-09-27 14:07:49.750 Using profile 'Live TV' to record
2009-09-27 14:07:49.751 TVRec(6): MPEG program number: 1
2009-09-27 14:07:49.751 DTVSM(0022CECC76B00000)::SetProgramNumber(1):
2009-09-27 14:07:49.751 SM(0022CECC76B00000)::RemoveFlags: Seen(PMT,Crypt,) Match(PMT,Crypt,) Wait()
2009-09-27 14:07:49.751 SM(0022CECC76B00000)::AddFlags: Seen() Match() Wait(PMT,)
2009-09-27 14:07:49.751 SM(0022CECC76B00000)::AddFlags: Seen() Match() Wait(PAT,PMT,Pos,)
2009-09-27 14:07:49.751 TVRec(6): Successfully set up MPEG table monitoring.
2009-09-27 14:07:49.751 SM(0022CECC76B00000)::Start: begin
2009-09-27 14:07:49.751 FireDev(0022CECC76B00000): Requesting STB Power State
2009-09-27 14:07:49.751 SM(0022CECC76B00000)::Start: end
2009-09-27 14:07:49.751 TVRec(6): SetFlags(SignalMonitorRunning,) -> RunMainLoop,SignalMonitorRunning,
2009-09-27 14:07:49.751 TVRec(6): ClearFlags(WaitingForSignal,) -> RunMainLoop,SignalMonitorRunni...

[MarcRandolph (mrand)]

Howdy again Mitchell,

Hmmm... it isn't obvious to me from the logs - is the problem that it
just produces zero byte recordings?
With a current --version output, we should be set to forward it upstream.

Thanks for your efforts on this!

[Mitchell (mitchell-gore)]

Sure,
mitchell@mythtv:~$ mythbackend --version
Please include all output in bug reports.
MythTV Version : 22072
MythTV Branch : trunk
Network Protocol : 48
Library API : 0.22.20090919-1
QT Version : 4.5.0
Options compiled in:
 linux debug using_oss using_alsa using_pulse using_jack using_backend using_dvb using_firewire using_frontend using_glx_proc_addr_arb using_hdhomerun using_hdpvr using_iptv using_ivtv using_joystick_menu using_libfftw3 using_lirc using_mheg using_opengl_video using_opengl_vsync using_qtwebkit using_v4l using_x11 using_xrandr using_xv using_xvmc using_xvmc_vld using_xvmcw using_bindings_perl using_bindings_python using_opengl using_vdpau using_ffmpeg_threads using_libavc_5_3 using_live using_mheg
mitchell@mythtv:~$

I think the issue is it cannot find a PAT.

Here is a link to a sample from my box. http://dl.getdropbox.com/u/1578989/test.mpg

Mitchell

[MarcRandolph (mrand)]

Probably should have been two tickets, one for channel changer and one for video. Changing to track the second (video) problem since the channel changer was fixed via (http://svn.mythtv.org/trac/ticket/6635).

[MarcRandolph (mrand)]

After waiting 8 months, the response from upstream was this:

<<The MythTV tuning code requires at least a PAT and PMT as per spec. Any attempt to add support for building a PMT on the fly based on the content of the data on the wire would be a feature request. It's a sufficiently rare case that I'm not really interested in implementing that feature myself. >>

If one of you can locate someone to help write a patch, it might, we'd be happy to help push to get it adopted.