[mythtv] Remove Fill Packets
ryanlavender at comcast.net
Thu Apr 30 18:22:43 UTC 2015
On 4/27/15, 10:35 AM, "Ryan Lavender" <ryanlavender at comcast.net> wrote:
> On 24/04/15 20:17, Ryan Lavender wrote:
>> > Hi Ryan,
>> > Ok, I've had a closer look at the code (not that I understand how all of
>> > it fits together) and it seems that this feature is not (currently)
>> > available for Firewire cards.
>> > stuarta has just pushed a change to Master to strip fill packets for
>> > Firewire recorders. _https://github.com/MythTV/mythtv/commit/b0138ce_
>> > should apply to 0.27 too so give it a go.
>> > Richard.
>> > Weird, but it doesnâ€™t work for me. I get 0-byte recordings. What I did
>> > to make it work was add this to firewiredevice.cpp:
>> > Put all of the content of the function BroadcastToListeners inside an IF
>> > statement: if(!(data == 0x1F && data == 0xFF))
>> > However, mythtv sometimes has trouble tuning certain channels, and I
>> > feel it may be related.
> I really don't know the code that well but I would guess that
> BroadcastToListeners is called whenever there is new data. That new
> data may not be the start of a packet, so your code will filter out
> chunks of data that happen to 0x1FFF in the 'wrong' place.
> I don't understand how the change stuarta made would cause 0-byte
> recordings unless *every* packet were padding (and then there would be
> nothing to watch anyway).
> Can you check that with no changes, everything works fine, but with the
> following, you get 0-byte recordings?
> bool FirewireRecorder::ProcessTSPacket(const TSPacket &tspacket)
> const uint pid = tspacket.PID();
> if (pid == 0x1fff) // Stuffing
> return true;
> That is what happened when I tried it the first time. Would you like me to try
> it again?
> Please. As I said, it doesn't really make sense that that change would
> cause 0-byte recordings but since I don't know exactly what code changes
> you made, and I don't have the hardware to test it myself, it would be
> good to make sure that the 0-byte recordings really only occur when only
> that change is made.
I’m going to test it again, but I think I should mention that I also have a
patch in my code modeled after https://github.com/MythTV/mythtv/pull/10. See
also the ticket: https://code.mythtv.org/trac/ticket/7205 . My cable box
doesn’t have PMT/PAT in the mpeg-ts stream. I think when I apply the patch
for the fill packets, it breaks my PSIP generation code.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the mythtv-dev