Opened 12 years ago
Closed 12 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 |
Description
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 http://www.gossamer-threads.com/lists/mythtv/dev/231271?search_string=opencable;#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)
Change History (4)
Changed 12 years ago by
| Attachment: | dvb_user_private_stream_type_0x80.patch added |
|---|
comment:1 Changed 12 years ago by
| Milestone: | unknown → 0.25 |
|---|
comment:2 Changed 12 years ago by
| Milestone: | 0.25 → unknown |
|---|---|
| Type: | Patch - Bug Fix → Bug 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 12 years ago by
| Resolution: | → Won't Fix |
|---|---|
| Status: | new → closed |
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?
Simple bug, simple patched supplied to fix