Help us testing the new TsWriter (3 Viewers)

[rtv]

I would like to use my TechnoTrend Card as secondary, because the Hauppauge is much more reliable... but If I do so, the TT generates only 0kb recordings if the primary card (the Hauppauge) is also busy (i.e. timeshifting).
When I configure the TT to be the primary card then everything works...

That's exactly what I've seen as well with TT3200 & SS2 already more than a year ago. I doubt tswriter can do much about it. Unfortunately we cannot force all users to trash all other tv cards and only use these over-expensive, not even linux-supporting Digital Everywhere products

Edit: On the other hand - when everything is okay having the TT3200 as first card - why not simply leave it as that?

 

[Ambass]

Hi gemx,

I think this section is better for the pmt length problem. I've only reached the IRC at 18h00 and seems no gemx !
Not a problem !

In the "CSectionDecoder::OnTsPacket(CTsHeader& header,byte* tsPacket)" I've added some log info to dump the TS packet, and to have the status after packet analysis.


void CSectionDecoder::OnTsPacket(CTsHeader& header,byte* tsPacket)
{
....
..... Simple Ts dump

.....

LogDebug("!!! CSectionDecoder: m_section.SectionComplete %d, m_section.section_length %d, m_section.BufferPos %d , start %d, pointer_field %d", m_section.SectionComplete(), m_section.section_length, m_section.BufferPos, start, pointer_field) ;
if (m_section.SectionComplete() && m_section.section_length > 0)
{
DWORD crc=crc32((char*)m_section.Data,m_section.section_length+3);
LogDebug("!!! CSectionDecoder: crc %d, m_bCrcCheck %d", crc, m_bCrcCheck) ;
........

17-02-2008 18:01:44.140 47 45 03 12 00 02 b0 b6 23 f4 f9 00 00 e0 a3 f0
17-02-2008 18:01:44.140 00 06 e0 27 f0 0a 59 08 66 72 61 20 00 03 00 04
17-02-2008 18:01:44.140 06 e0 5e f0 4a 6a 02 80 44 0a 04 66 72 61 00 09
17-02-2008 18:01:44.140 3e 01 00 f6 09 33 15 ff 00 00 04 00 00 00 00 60
17-02-2008 18:01:44.140 24 51 f6 08 33 11 ff 00 00 0c 02 04 00 00 00 24
17-02-2008 18:01:44.140 51 e6 68 00 80 ff 00 00 00 00 04 00 00 00 24 51
17-02-2008 18:01:44.140 e6 69 00 81 ff 00 00 00 10 04 00 00 00 24 51 1b
17-02-2008 18:01:44.140 e0 a3 f0 46 28 04 03 00 03 00 09 3e 01 00 f6 09
17-02-2008 18:01:44.140 33 15 ff 00 00 04 00 00 00 00 60 24 51 f6 08 33
17-02-2008 18:01:44.140 11 ff 00 00 0c 02 04 00 00 00 24 51 e6 68 00 80
17-02-2008 18:01:44.140 ff 00 00 00 00 04 00 00 00 24 51 e6 69 00 81 ff
17-02-2008 18:01:44.140 00 00 00 10 04 00 00 00 24 51 83 df
17-02-2008 18:01:44.140 !!! CSectionDecoder: m_section.SectionComplete 0, m_section.section_length 182, m_section.BufferPos 183 , start 188, pointer_field 5

17-02-2008 18:01:44.156 47 05 03 13 48 68 ff ff ff ff ff ff ff ff ff ff
17-02-2008 18:01:44.156 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
17-02-2008 18:01:44.156 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
17-02-2008 18:01:44.156 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
17-02-2008 18:01:44.156 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
17-02-2008 18:01:44.156 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
17-02-2008 18:01:44.156 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
17-02-2008 18:01:44.156 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
17-02-2008 18:01:44.156 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
17-02-2008 18:01:44.156 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
17-02-2008 18:01:44.156 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
17-02-2008 18:01:44.156 ff ff ff ff ff ff ff ff ff ff ff ff
17-02-2008 18:01:44.156 !!! CSectionDecoder: m_section.SectionComplete 1, m_section.section_length 182, m_section.BufferPos 185 , start 6, pointer_field 0
17-02-2008 18:01:44.156 !!! CSectionDecoder: crc 0, m_bCrcCheck 1

This show the correct result after comparing BufferPos-3 to section_length in "SectionComplete()"


When the "-3" is not present, the result after the first packet is BufferPos = 183 , greater than section length (182 ), so the section appears as complete, and the crc normally fails...

I think in the old TsWriter, section_length was including bytes 5,6 & 7 of the 1st TS packet, so probably 185 for a real 182 PMT size.

If the my office web is working, I'm connected on IRC.


Regards.

Ambass.

 

[gemx]

ambass
Yep, you are right.
I re-commited the changes again

 

[Ambass]

gemx,

but the problems with this f..g channel are not closed. ( therefore this probably help us to debug some special situation.. )

There is now a problem that seems on the TsReader side, I suspect it's the same pmt size issue. ( I've not have a look at the TsReader, it's just a feeling, may be I'm wrong !)

The problem is this ( in 3 different cases ) :

1) Changing any channel from SD to TF1 HD do not show any picture or sound.
- TvService has changed channel properly, Tv/TsWriter log are Ok.
- TsReader has not detected any channel change => Graph shows Video codec is the Mpeg2 one !!

Switching now to another HD channel rebuild the graph with H264 decoder and works.

2) Switching any channel from SD to other HD channel works. ( graph rebuild from MPEG2 to H264 codec )

3 ) Switching form another HD channel to TF1 HD works (.... No need to rebuild the graph... )

In parallel, I've done some snapshots of the timeshift buffers and playing them do the same result.

Cutting them in order to start directly with PAT/(TF1)PMT ts packets, TSReader do not read anything.
PowerDVD can read them properly, so, they probably are correctly recorded.

The thing I suspect, it's the fact that TsReader do not decode properly the 182 bytes PMT, ignore it and continue with the previous channel PMT.
So, when the previous channel is also an H264/AC3 channel, due to the "fake unchanged Pids" TsReader works without seeing any channel change an all seems ok, but when previous channel is MPEG2, due to the same "fake unchanged Pids" nothing change, and the graph is not rebuilt for H264.

It's just an hypothesis, may be not so bad !!


I don't know if you work on the Ts Reader, but..
What are you thinking about this ?

Regards.

Ambass.


Ps : I've also 2 other problem :

-- one for dman ( already asked ), but all ideas are welcomed.
I need to send twice the PMT table to the CAM to have it decoding 4 HD channels ( 3 other works normally )
( FloppyDTV-S2 / CAM Astoncrypt 2.18 )

-- TsReader is crashing ( XP crash windows says TsReader... ) after a while ( from some mins to a lot of hours ).
Seems not related to specific SD or HD channel. MP continues to work until I close the XP crash window.
( Absolutly not WAF !! )

I'll continue to investigate....

 

[gemx]

thanks for your efforts.
We have to investigate the issue with changing channels deeper.
I agree that it's a TsReader bug but i put the section decoding stuff in a static library (DvbCoreUtils) which is used by TsReader and TsWriter.
So if we change the section decoding we change it for both filters.
There must be another bug

 

[Ambass]

:sorry: gemx,

I've made an horrible release mix on my PC....

The analysis was really good , It was the same bug, just the my TsReader was not updated.


Therefore, the 2 "post scriptum" problems are present since I strated the HTPC ( November 2007 ), and are always true.


Sorry again.

Regards.


Ambass.

 

[chemelli]

gemx,

I still have a issue with TsWriter.ax, test was done like follow:

- stop tvservice
- clean logs
- start tvservice
- start SetupTv
- go in manual control
- start timeshifting on Rete4,Italia1,SportItalia: error channel is scrambled.

With FloppyDTV-S2 viewer I can see those channels so there is something else in TsWriter.ax alghoritm...

If you want to connect directly on my pc, contact me on IRC/Skype.

Simone

 

[iosub]

Hi
I'm also having "strange" problems with FireDTV-C.. since some builds ago, I didn't have before.
Some times my first card gets locked forever.. even after I stop TVService.(fireDTV Log attached) and my second card get and "error"

The only Solution, "shutdown computer, Unplug from the power the FireDtv-C cards..
FireDTV log:

FireDTV / FloppyDTV devices:
-------------------------------------------------------------------------------
devices found: 2

Status for device 1
Model : FireDTV C/CI
GUID : 0x00128700360009EF
HW Ver.: 01.36.01
FW Ver.: 1.3.0 Build 44650
Driver : 4.8.0

Frontend Status:
Power Supply: 12.12V
1394 Bus: 11.76V
Frequency.: 738000 kHz, Sig.Str.: 100%, BER: 0
Locked : YES

CAM Module: Predasaur 2.25

Status for device 2
Model : Error
GUID : 0x00128700360022FD
HW Ver.: 00.00.00
FW Ver.: 0.0.0 Build 0
Driver : 4.8.0

Frontend Status:
Frequency.: 0 kHz, Sig.Str.: 0%, BER: 0
Locked : NO

No CAM Module inserted

====================
Today, I have try disabling EPG idle and EPG TimeShift
I will tell you something

Iosu

 

[iosub]

StreamingServer.log error "Missing sync byte!"

Hi

While a schedule recording is in place I have select from a MP client on the Guide the channel that is recording
I get two options:

1.- "from the begining" Nothing happen no picture no audio
2.- "from the live point" I see video and audio but my secord tunner is selected instead the one is recording

I have see that on the streamingserver.log the is an error "Missing sync byte!"

I have add the the logs.

This is build 17471

Iosu

 

[chemelli]

gemx,

I started with a clean install of 17523 (new db, new settings, new scan) and I can see that channels too.

Simone