Opened 9 years ago

Closed 9 years ago

#10346 closed Bug Report - General (Won't Fix)

Stream_type 0x80 is not video in DVB

Reported by:… Owned by: danielk
Priority: minor Milestone: unknown
Component: MythTV - DVB Version: Master Head
Severity: low Keywords: opencable, dvb, pmt
Cc: Ticket locked: no


In my DVB-C cable system are TV channels that cannot be recorded by MythTV. However, they can be recorded with gnutv and the resulting recordings can be played by MythTV when placed in a Video directory.

Analyzing the streams recorded with gnutv shows that there is a private data stream with stream_type of 0x80 present. This stream is erroneously identified as an OpenCableVideo? stream in MythTV.

This problem has been identified before (see #2556 and the thread;#231271) and the fix was to use the first identified video stream as the real video stream. This worked because in #2556 the 0x80 stream came after the real video stream. However, I have TV channels where the 0x80 stream is seen first so this does not work for me.
I've fixed this by adding a new IsVideo? function that also checks that the sistandard is "opencable" when the stream_type is recognized as OpenCableVideo? (0x80). I have also changed the test in StreamID::Normalize to check explicitly on "opencable".

There are changes in mpegstreamdata.cpp, mpegtables.h and mpegtables.cpp. Patch is attached.

Attachments (1)

dvb_user_private_stream_type_0x80.patch (2.4 KB) - added by… 9 years ago.

Download all attachments as: .zip

Change History (4)

Changed 9 years ago by…

comment:1 Changed 9 years ago by stuartm

Milestone: unknown0.25

Simple bug, simple patched supplied to fix

comment:2 Changed 9 years ago by danielk

Milestone: 0.25unknown
Type: Patch - Bug FixBug Report - General

As is this patch will break ClearQAM tuning in the US because we rarely detect that as actually being open cable.

comment:3 Changed 9 years ago by danielk

Resolution: Won't Fix
Status: newclosed

If you can come up with a patch that won't break US TV recording, please attach and I'll reopen. Otherwise this would be trading a small problem for a big one..

Maybe we could try scanning for video not of type 0x80 first, then scan for type 0x80 video only if other video is not found?

Note: See TracTickets for help on using tickets.