reeh Posted September 30, 2006 Share Posted September 30, 2006 (edited) The TV3 channel on the primary Danish cable network, TDCkabelTV, cannot be received with DVBViewer. All other channels - encrypted and free - shows and records with no problems. The channel is receivable with other programs - such as TechnoTrend BDA Mediacenter. Hardware: Medion 8883 - 3.2GHz P4 HT - 1GB RAM ATI Radeon 740XL Graphics TechnoTrend Budget C-1500 Cable Receiver Technotrend Budget PCI CI Viaccess I/II CAM (V484) TDCKabelTV smartcard Software: WinXP Home SP2 - all updates TechnoTrend BDA Driver version 4.4.10.17 DVBViewer 3.5 PRO - DVB Source 2.8.0 and 2.8.1 Video- and audio decoders tried: CyberLink, Nero, and InterVideo 'ttAPI.dll' posted by 'hackbart' on Aug 19 2006, 01:26 PM Support.zip included ... I have tried to investigate as best possible with the tools easily available to me. So please accept the rather long story to follow ... I have also included an attachment with numbered screen dumps ... First, however, let me share my prime suspicion: TV3 is - as far as I have seen - the only channel that shares PMT PID with another channel in the same multiplex (see screen dumps #1 and #3). I suspect this results in DVBViewer or DVB Source failing to set up decryption properly or demux properly. Now for the more elaborate part ... The TV3 channel shares multiplex with a number of other channels (see screen dumps #1, 3, 4, 6, 7, and 9). In this report I focus on three channels: Channel, PMT PID, Video PID, Audio PID, Teletext PID TV3, 257, 210, 211, 212 TCM, 257, 270, 271, 272 SVT1, 36, 220, 221, 222 Two of these, TV3 and TCM, share the same PMT PID. SVT1 has its own PMT PID. Not surprisingly, the shared PMT PID (257) carries double the information of the other PMT PIDs (see screen dumps #3, 6, and 9). Unfortunately, I do not have a tool that allows me to analyze the streams further ... When selecting the TV3 channel, the brief EPG display shows up properly. The brief EPG display shows the proper EPG info, that the channel has Teletext, and that the channel is encrypted. The video freezes at the latest frame from the previous channel, and there is no sound. Teletext is avaiable and is updated. The asterix ('*') indicating an encrypted channel remains in the status line. The DVB Source filter panel shows 'connected / no data' (see screen dump #2). The clock (PCR) in the panel is updated. Using Video Recorder to show all PIDs for the multiplex, it seems that the video and audio PIDs for the TCM channel (PID 270 and 271) are wrongly decoded, also when TV3 is selected as channel (see screen dump #3) When selecting the TCM channel everything works as expected (screen dumps #4, 5, and 6). Not surprisingly, everything works OK with SVT1 (screen dumps #7, 8, and 9). Both TV3, TCM and SVT1 are encrypted. My smartcard does allow access to TV3 - as stated in the beginning, TV3 is available using TechnoTrend BDA Mediacenter. As indicated above, I have tried the the two DVB Source versions available to me, and I have tried different codecs. -- Erik Reeh support.zip Screen_Dumps_1_9.zip Edited October 1, 2006 by reeh Quote Link to comment
Derrick Posted September 30, 2006 Share Posted September 30, 2006 Unfortunately, I do not have a tool that allows me to analyze the streams further ... ..yes, you have ! Thanks to @Griga Take the latest TransEdit from the member's area, select the cable channel and click on analyse. Then left upper corner -> Transponder and bottom left -> save as XML. Please attach this file zipped together with the pid_statistic Quote Link to comment
reeh Posted October 1, 2006 Author Share Posted October 1, 2006 (edited) ... TransEdit ... analyse ... XML ... pid_statistic ... I have collected and zipped the analysis data (XML and PID statistics) as requested. Unfortunately the forum rules does not allow me to attach the file - it is 447 KB versus the 44 KB I am allowed. I have put the zip-file for download at http://reeh.dk/DVBViewer/Kabel_(QAM_64)_6875MSs_554000.zip In case it will be useful, I have also put a 30 second dump (zipped .ts) of the complete multiplex that carries TV3 at http://reeh.dk/DVBViewer/Kabel_(QAM_64)_68...01_08-37-13.zip -- Erik In addition: In the original software lineup I forgot to mention that, in order to get CI and decryption to work, I had to install the updated 'ttAPI.dll' that 'hackbart' posted on Aug 19 2006, 01:26 PM in 'DVBViewer community forum > Digital Video Broadcasting > HDTV' ... Edited October 1, 2006 by reeh Quote Link to comment
Derrick Posted October 1, 2006 Share Posted October 1, 2006 Thx, as expected (cos you've already had the correct teletext_PID) there's nothing wrong with the parsing of the stream with PMT_PID=257. It is not unusual to use different sections in one PMT_PID for different services. I still don't know what's wrong. Maybe the DVBViewer sends a wrong CA_PMT but that I can't see from the files. Quote Link to comment
Guest Lars_MQ Posted October 1, 2006 Share Posted October 1, 2006 For TT cards the DVBViewer simply sends the complete PMT as delivered from the DVB card, everything else is done by the ttdll/driver/card combo. you could start the DVBViewer with the -debug commandline option, it will then create a debug.log in the DVBViewer folder. Please zip and post this log. Quote Link to comment
Derrick Posted October 1, 2006 Share Posted October 1, 2006 For TT cards the DVBViewer simply sends the complete PMT as delivered from the DVB card Do you mean the corresponding section filtered according to the SID? Quote Link to comment
reeh Posted October 1, 2006 Author Share Posted October 1, 2006 ... you could start the DVBViewer with the -debug commandline option, it will then create a debug.log in the DVBViewer folder. Please zip and post this log. I have run three tests with the -debug option. I am including the three logs in a zip-file, debug.log.zip, containing: 1-debug.log, 2-debug.log, 3-debug.log. In 1-debug.log DVBViewer was started with STV1 (on the same multiplex as TV3) selected - decryption, video and sound OK. At 13:29 TV3 was selected - encryption star stays on, no video or sound. At 13:30 TCM (sharing PMT PID 257 with TV3) was selected - all OK. At 13:31 STV1 was selected again - all OK. In 2-debug.log DVBViewer was again started with STV1 - all OK. At 13:38 DR1 (unencrypted, on a different multiplex) was selected - all OK. At 13:40 TV3 was selected - encryption star stays on, no video or sound. At 13:41 TCM was selected - all OK. At 13:42 TV3 was selected again - same symptoms. In 3-debug.log DVBViewer was started with TV3 selected - encryption star stays on, no video or sound. It was left running for a while and then closed ... I am afraid they do not show much Some module chose to speak Danish in the log files - "Handlingen er gennemført" means "Action completed" debug.log.zip Quote Link to comment
reeh Posted October 1, 2006 Author Share Posted October 1, 2006 For TT cards the DVBViewer simply sends the complete PMT as delivered from the DVB card, everything else is done by the ttdll/driver/card combo. ... Apologies for asking a potentially stupid question - since I do not know the internals of DVBViewer and not too much about DVB, but... How does the 'ttdll/driver/card combo' decide what PIDs to process, when it is fed a PMT stream with two channels ? As stated in my original posting (probably not very clearly) - and illustrated by screen dumps #3 - it seems that when TV3 is selected, the TCM channel PIDs 270 and 271 are decrypted. The TV3 PIDs 210 and 211 are not. TCM is the other channel sharing the PMT PID 257 ... Quote Link to comment
Derrick Posted October 1, 2006 Share Posted October 1, 2006 If other applications are decrypting this channel with the same "ttdll/driver/card combo" the bug has to be located inside the DVBViewer. I don't have any part of this "combo" Certain CASs (e.g. nagra) use shared PMTs for many services. If somebody has a module/card for D+ on hispasat, he could tell whether this works with DVBViewer or not. I'm afraid there won't be many users and if they'll probably have seca and watch the programmes from astra. But there you'll find the normal PMT structure exept for some radio channels and those are FTA btw. the sections in PMT 0x0101 are alternating between: Program 210 TV3 02B04500D2D30000E0D2F00002E0D2F011090F0500E057100100130120140302030803E0D3F01109 0F0500E057100100130120140302030806E0D4F007560564616E0900FB9CC4D3 - CRC OK 02 -> table_id: program_map_section 0045 -> section_length PMT 69 bytes 00D2 -> program number 09 -> version number 01 -> current_next_indicator 00 -> section number 00 -> last section number 00D2 -> PCR Pid F000 -> and 0FFF = 0000 program info length 0 bytes 02 -> ITU-T Rec. H.262 | ISO/IEC 13818-2 Video or ISO/IEC 11172-2 constrained parameter video stream E0D2 -> and 1FFF = 00D2 F011 -> ES_info length 17 Bytes 090F -> CA_descriptor length 15 bytes 0500 -> France Telecom ("Viaccess") E057 -> and 1FFF = 0057 ECM-Pid 1001 -> Unknown Viaccess descriptor length 1 bytes 00 1301 -> Unknown Viaccess descriptor length 1 bytes 20 1403 -> Viaccess Provider descriptor length 3 bytes 02030 -> Provider Unknown Service Operator 8 -> Key in use: 08 03 -> ISO/IEC 11172 Audio E0D3 -> and 1FFF = 00D3 F011 -> ES_info length 17 Bytes 090F -> CA_descriptor length 15 bytes 0500 -> France Telecom ("Viaccess") E057 -> and 1FFF = 0057 ECM-Pid 1001 -> Unknown Viaccess descriptor length 1 bytes 00 1301 -> Unknown Viaccess descriptor length 1 bytes 20 1403 -> Viaccess Provider descriptor length 3 bytes 02030 -> Provider Unknown Service Operator 8 -> Key in use: 08 06 -> ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data E0D4 -> and 1FFF = 00D4 F007 -> ES_info length 7 Bytes 5605 -> teletext_descriptor length 5 bytes 64616E -> ISO 639_language_code: dan -> Danish 09 -> teletext_type 01: initial Teletext page -> teletext_magazine_number: 1 00 -> teletext_page_number and Program 270 TCM 02B04A010ED30000E10EF00002E10EF011090F0500E02F100100130120140302030804E10FF01109 0F0500E02F100100130120140302030806E110F00C560A64616E178664616E0F56F4EC6B56 - CRC OK 02 -> table_id: program_map_section 004A -> section_length PMT 74 bytes 010E -> program number 09 -> version number 01 -> current_next_indicator 00 -> section number 00 -> last section number 010E -> PCR Pid F000 -> and 0FFF = 0000 program info length 0 bytes 02 -> ITU-T Rec. H.262 | ISO/IEC 13818-2 Video or ISO/IEC 11172-2 constrained parameter video stream E10E -> and 1FFF = 010E F011 -> ES_info length 17 Bytes 090F -> CA_descriptor length 15 bytes 0500 -> France Telecom ("Viaccess") E02F -> and 1FFF = 002F ECM-Pid 1001 -> Unknown Viaccess descriptor length 1 bytes 00 1301 -> Unknown Viaccess descriptor length 1 bytes 20 1403 -> Viaccess Provider descriptor length 3 bytes 02030 -> Provider Unknown Service Operator 8 -> Key in use: 08 04 -> ISO/IEC 13818-3 Audio E10F -> and 1FFF = 010F F011 -> ES_info length 17 Bytes 090F -> CA_descriptor length 15 bytes 0500 -> France Telecom ("Viaccess") E02F -> and 1FFF = 002F ECM-Pid 1001 -> Unknown Viaccess descriptor length 1 bytes 00 1301 -> Unknown Viaccess descriptor length 1 bytes 20 1403 -> Viaccess Provider descriptor length 3 bytes 02030 -> Provider Unknown Service Operator 8 -> Key in use: 08 06 -> ITU-T Rec. H.222.0 | ISO/IEC 13818-1 PES packets containing private data E110 -> and 1FFF = 0110 F00C -> ES_info length 12 Bytes 560A -> teletext_descriptor length 10 bytes 64616E -> ISO 639_language_code: dan -> Danish 17 -> teletext_type 02: Teletext subtitle page -> teletext_magazine_number: 7 86 -> teletext_page_number 64616E -> ISO 639_language_code: dan -> Danish 0F -> teletext_type 01: initial Teletext page -> teletext_magazine_number: 7 56 -> teletext_page_number Quote Link to comment
Guest Lars_MQ Posted October 1, 2006 Share Posted October 1, 2006 Well maybe the Program number in the channellist is wrong. For everything else we have to wait until christian is back. CI is his toy. The only thing I can say is: the card is detected ok, the cam is detected ok, the settuner is working with no errors in the CI and the PMT is send to the ttdll with no error. So from my part there is nothing more to be done. Quote Link to comment
Derrick Posted October 1, 2006 Share Posted October 1, 2006 Well maybe the Program number in the channellist is wrong. no, everything that can be seen has been double checked by @reeh and me. The settings, as shown by the screenshots, are correct. But @reeh did a good job. He made a remark twice, that I've overlooked it seems that the video and audio PIDs for the TCM channel (PID 270 and 271) are wrongly decoded, also when TV3 is selected as channel (see screen dump #3) As stated in my original posting (probably not very clearly) - and illustrated by screen dumps #3 - it seems that when TV3 is selected, the TCM channel PIDs 270 and 271 are decrypted. The TV3 PIDs 210 and 211 are not. TCM is the other channel sharing the PMT PID 257 ... For me it seems that there are 2 different sets of filters. The module has got a set (of the wrong service) while the source filter is trying to receive the correct elementary streams but these remain scrambled. Clear case of WYSINWYG Quote Link to comment
reeh Posted October 1, 2006 Author Share Posted October 1, 2006 (edited) Well maybe the Program number in the channellist is wrong. ... In an attempt to eliminate any doubts about the channel list, I did a re-scan of the TDCkabelTV connection. The TV3 settings came up the same as before - compare the Channel Editor screen dump enclosed with screen dump #1 from my original posting. The Channel Editor settings also seem to match what would be expected from the TS Analyzer output - see enclosed screen dump and/or XML file previously posted. Just for the fun of it, I played around with ONLY the video-PID for TV3. I tried all meaningful PIDs from the multiplex: 210, 220, 230, 240, 260, 270 and 280. Only PID 270 gave a result: The video from TCM the channel sharing PMT PID with TV3 was shown. Finally, as a sanity check, I just checked the availability of TV3 with TT BDA Media Center - same driver at least ... Everythig OK! Anyway, thank you! - For giving this a serious look -- and on a Sunday ...For me it seems that there are 2 different sets of filters. The module has got a set (of the wrong service) while the source filter is trying to receive the correct elementary streams but these remain scrambled. ... I agree about "triyng to receive the correct elementary streams but these remain scrambled" - TV3 streams 210 and 211 - while two other streams - TCM streams 270 and 271 - are being decrypted. Thanks 'Derrick' for stating this so clearly ! Edited October 1, 2006 by reeh Quote Link to comment
Guest Lars_MQ Posted October 1, 2006 Share Posted October 1, 2006 Do you maybe know of other people having the same problem with this channel but another (non-TT) card? maybe firedtv. I just want to exclude any problems with the ttdll (either in the dll itself or the way we use it). I checked the complete source in question 3 times now and for all I can see is the correct pmt must be send to the CI module (means ttdll) because that's excactly the same module (for the pmt) doing the pmt detection in the liveTV and we would get serious trouble with other channels sharing a pmt also... Derrick himself told christian to add the SID check in the pmtparser if I remember right... Quote Link to comment
reeh Posted October 1, 2006 Author Share Posted October 1, 2006 (edited) Do you maybe know of other people having the same problem with this channel but another (non-TT) card? maybe firedtv. I just want to exclude any problems with the ttdll (either in the dll itself or the way we use it). ... 'Lebeck' posted the same problem concurrently with me yesterday in this forum - Topic: 'Viasat TV3'. He states that he has a ' FireDTV-C TV Tuner - BDA Driver Version: 4.2 - Firmware: 1.2.1'. He is also receiving from the Danish TDCkabelTV network. I cannot see if he has the proper CI/CAM equipment. I will ask in his thread ... (Answer was: YES, have CI/CAM - see below. Same problem. FireDTV ...) Edited October 1, 2006 by reeh Quote Link to comment
Derrick Posted October 1, 2006 Share Posted October 1, 2006 @reeh, it's always a pleasure when a user provides so much evidence I have to come back to my initial statement. The CA_PMT has to be wrong. Otherwise, who told the module to descramble the wrong streams? I asked whether the correct program_map_section was sent. Maybe the "combo" gets everything and decides to take the higher service_id which would explain why in both cases SID 270 is chosen. I don't have any proof cos the ca_pmt is not shown. Here is a screen shot from 30W with the mentioned shared_PMT_PID. Alas I don't have the decryption means.. Quote Link to comment
Lebeck Posted October 1, 2006 Share Posted October 1, 2006 I have proper CI/CAM equipment: Viaccess card version 4.84 and "TDC Kabel TV" card. Actually I have firmware 1.2.2 on my FireDTV-C tuner - It was a mistake when I wrote 1.2.1 Quote Link to comment
reeh Posted October 1, 2006 Author Share Posted October 1, 2006 ...I checked the complete source in question 3 times now ... I know the feeling Anyway, I will ask again - even though I may be on thin ice ... Apologies for asking a potentially stupid question - since I do not know the internals of DVBViewer and not too much about DVB, but... How does the 'ttdll/driver/card combo' decide what PIDs to process, when it is fed a PMT stream with two channels ? Is it the PMT stream (PID 0x0101 for both TV3 and TCM) or the CA stream (PID 0x0057 for TV3, 0x002F for TCM) that is being sent to the 'ttdll/driver/card combo' ? Quote Link to comment
Derrick Posted October 1, 2006 Share Posted October 1, 2006 Is it the PMT stream (PID 0x0101 for both TV3 and TCM) or the CA stream (PID 0x0057 for TV3, 0x002F for TCM) that is being sent to the 'ttdll/driver/card combo' ? ..that's in fact my question as well. A pmt ist a table that consists of sections characterized by a program number. The stream has to parsed by a section filter (everything can be found in ISO 13818-1). According to the CI_standard, the host (here the DVBViewer) has to send a ca_pmt to the application (the module in the standard). There can be some minor differences about what a ca_pmt should contain, but certainly not more than a single section. Without shared_pmt this would be of course not possible Quote Link to comment
Guest Lars_MQ Posted October 1, 2006 Share Posted October 1, 2006 Neither. The PMT-Section for the stream with the PMTPID and SID is send to the dll. The dll/driver/card (don't know how it's done there) seems to process the PMT, extracts the ECMPIDs etc from it and handles everything completely transparent for the DVBViewer. So what happens when you set a channel? First a fitting device(a device or hardwareclass is the internal representation of a actual hardware dvb-card) is located. This device is fed with the Tunerstructure of the channel containing all necessary data. In the device two things happen, the tuning itself (setting all parameters to the card) and the CI Module-Class gets also the tunerdata if there is a CI. The CI Module Class creates from the tunerdata a fitting PMTParser instance (with PMT PID and SID). After that the "Softfilters" are set. Means the hardwareclass gets told which parts from the complete stream (as BDA devices deliver it) are to process (identified by the PID). Mind you we use the whole time the same tunerrecord. After all is done the stream starts to flow. It goes through the softfilter in the hardware class and is distributed to all interessted parties (EPG-Parser, Teletext, subtitels, PMT-Parser, dvbsource etc) and if the PID of the packet has a PMT PID also to the CIModuleclass. The CIModuleClass feds the packets it gets to its own PMTParser till he says: "ok enough I have a complete PMT section for you". (The PMTParser gets all PMT Packets for the PMTPID but since he only uses the packets with the fitting SID the result must be the correct PMT-Section). This PMT section is fed to the ttdll (exactly the way it was received in form of a bytearray) and the dll kicks in. the previous encrypted packets now arrive decrypted and are send to the dvbsource. Which now can push the packets into the display graph. I think someone with such a detailed (and professional) problem description and analysis deserves for sure a detailed answer. @Derrick: Unfortunatly (as I explained earlier in another thread to you) every DVB-Card producer has his own recipe how the CI Module (this means the Driver or other software parts outside the DVBViewer) is to be fed. One needs a CA-PMT, the next only wants the PMT, Video and Audio PIDs, another one wants a complete PMT Section, one wants a PMT section with PIDs in reversed Byte-order or they want a own data structure to be filled and send. Quote Link to comment
boborg Posted October 1, 2006 Share Posted October 1, 2006 Also have Viaccess card version 4.84 and "TDC Kabel TV" card. Firmware 1.2.2 on my FireDTV-C tuner. And experiencing the same issue. Quote Link to comment
reeh Posted October 1, 2006 Author Share Posted October 1, 2006 (edited) ... I think someone with such a detailed (and professional) problem description and analysis deserves for sure a detailed answer. Thanks! - I am flattered ... ... and I appreciate the explanation ... but I am afraid I need another ½ hour to come up with a solution As you may have guessed, I have tried things from your side as well. I guess you will let me know, if you think I can do more ... Edited October 1, 2006 by reeh Quote Link to comment
Derrick Posted October 1, 2006 Share Posted October 1, 2006 @Derrick: Unfortunatly (as I explained earlier in another thread to you) every DVB-Card producer has his own recipe how the CI Module (this means the Driver or other software parts outside the DVBViewer) is to be fed. One needs a CA-PMT, the next only wants the PMT, Video and Audio PIDs, another one wants a complete PMT Section, one wants a PMT section with PIDs in reversed Byte-order or they want a own data structure to be filled and send. It happens with different "combos". It is working ok with other dvb_applications. Your enumeration of the different possibilities is also limited to a single section. The CI_stuff you are dealing with, implements the control interface. Parsing of the relevant tables has to be done by the dvb_application. So, who is telling the CI to filter the pids of a different section? Where does this knowlegde come from if not from the DVBViewer? Quote Link to comment
Guest Lars_MQ Posted October 1, 2006 Share Posted October 1, 2006 Since it is obviously a problem in the DVBViewer, I'll make a debug version with extensive logging and I'll send it to you, so we get to the bottom of it Where does this knowlegde come from if not from the DVBViewer? My guess it's a problem in the PMT-Parser. But unfortunatly it's not the new one (also used in the transedit for the analysis) but the old one, effective but man it's complicated. I'll have to see how much I can do without christian. I tended to avoid this code part Quote Link to comment
reeh Posted October 1, 2006 Author Share Posted October 1, 2006 (edited) Since it is obviously a problem in the DVBViewer, I'll make a debug version with extensive logging and I'll send it to you, so we get to the bottom of it ...I will give it a 'spin' as soon as I get my hands on it ... Once more, thanks a lot for your effort ! Anyway, I can easily live a few days with the problem ... I am home tomorrow all day - but traveling the rest of the week. Edited October 1, 2006 by reeh Quote Link to comment
Derrick Posted October 1, 2006 Share Posted October 1, 2006 My guess it's a problem in the PMT-Parser. Are there different parsers in the code? I ask this because I've run a test comparing the results of transedit and DVBViewer-pro. The object was one of the shared_pmt transponders on 30W. The ini from transedit and the exported ini from the pro-scan were identical. But that is only what can be observed from the outside world Quote Link to comment
Guest Lars_MQ Posted October 1, 2006 Share Posted October 1, 2006 Are there different parsers in the code? It's a little more complicated. the channelscanner uses in both versions (DVBViewer and transedit) the "old" code. The new code is only used in the transedit analyser. The "old" code is also used for the CI-Stuff and for the ts recordings in DVBViewer with multiple audio & co and it is used in the liveTV part. The "new" code is more than only the PMT Part, it's a (relativly) complete and iso conform SI-Parser now used for the EPG parser, the premiere epg and in most of my plugins (if they need a parser). It is also meant to be the base for the new channelstuff I have in mind. Quote Link to comment
reeh Posted October 1, 2006 Author Share Posted October 1, 2006 Once more - threading on thin ice, but ... Having studied and interpreted Lars_MQ's description and Derrick's PMT analysis, it is hard not to believe that the 'combo' is passed the TCM PMT-section rather than the TV3 section. Thus, the PMT-parser does not deliver the PMT-section corresponding to the SID requested ... I guess this is also Lars_MQ's and Derrick's analysis ... The 'olde' bug hunter could ask: Does the PMT-parser happen to deliver both PMT-sections - with the TCM section 'first' ? Are we facing a 'race condition' in concurrent code - i.e. a new PMT-section arrives and overwrites the intended one ? Hard to guess without source code - and probably also with So, I guess I will have to wait until I can collect some more debug info -- and let the experts do the analysis ... Quote Link to comment
Derrick Posted October 1, 2006 Share Posted October 1, 2006 The 'olde' bug hunter could ask: Does the PMT-parser happen to deliver both PMT-sections - with the TCM section 'first' ? Are we facing a 'race condition' in concurrent code - i.e. a new PMT-section arrives and overwrites the intended one ? As I said, the 2 sections are alternating. You have to filter the section with the wanted SID. I'm pretty sure @Lars will find the bug Quote Link to comment
reeh Posted October 2, 2006 Author Share Posted October 2, 2006 Just to let you know: Lars has isolated and fixed the problem. I am sure he will post more info, when he gets the time. @Lars_MQ - Thanks a lot ! Quote Link to comment
Guest Lars_MQ Posted October 2, 2006 Share Posted October 2, 2006 Well the bug was in the pmtparser. With a lot of debug testing from reeh and the help of a calculator I was able to realize that a TSPacket (188 bytes) can contain 2 PMT-Sections in this case (about 80 bytes each). So what happened was: The CIModuleclass added a packet, the parser said it had a section but the detection of wrong SID in the section was placed to late (in the code) so the wrong section (means second in the TS-Packet) got into the buffer which is send to the ttdll. I corrected this, now christian has to verify this breaks nothing else (when he is back from vacation) and we will then publish a new beta. Quote Link to comment
Derrick Posted October 2, 2006 Share Posted October 2, 2006 congratulation if you've fixed the bug, but there is something weird in your story I was able to realize that a TSPacket (188 bytes) can contain 2 PMT-Sections in this case (about 80 bytes each). This is of course possible. Also that the max. section length of 1024bytes will span more than one ts_packet For a section filter this should be no problem.. In our case your finding is imho of no particular relevance cos there is no single ts_packet with pid 0x0101 that contain more than a single section. At least not in the sample provided by @reeh. There are 615 packets with 0x0101 and the length is about 30s. If 2 sections in a single packet could cause this error then there should have been enough time inbetween these packets to successfully descramble this channel.. ps. likewise with your explanation the other program (TCM) should have experienced the same problem, depending on which packet arrives 1st Quote Link to comment
Guest Lars_MQ Posted October 2, 2006 Share Posted October 2, 2006 Also that the max. section length of 1024bytes will span more than one ts_packet I'm quite aware of this, otherwise neither transedit analyse nor the EPG in the Pro would work In this special case there where two sections in one packet and the combination "old" PMT-Parser and CIModuleClass didn't took it into account. Since the code is from christian I'll have to check with him, if there was a reason to do it this way. Quote Link to comment
Derrick Posted October 2, 2006 Share Posted October 2, 2006 check yourself.. pid_stream 0x0101 of the 30s mux_dump from @reeh. No packet with 2 sections.. Quote Link to comment
reeh Posted October 2, 2006 Author Share Posted October 2, 2006 (edited) congratulation if you've fixed the bug I guess I am the witness here ... TV3 and TCM - and the rest - plays OK in the debug version I have tested ... ... the other program (TCM) should have experienced the same problem, depending on which packet arrives 1st When looking at the debug output I was puzzled by the lack of symmetry, but assumed that this is due to the packaging and sequencing of the packages. ... but the detection of wrong SID in the section was placed to late (in the code) ...... there is something weird in your story My suspicion would be - on thin ice again - that the important change is that the SID detection now catches all packages. I wonder if the 'packages' discussed are different concepts ? 'Derrick' talks about ts-packages, and 'Lars_MQ' talks about the packages feed to the CI-module in DVBViewer ... Another thought, @ Derrick: The lack of symmetry between TV3 and TCM makes me think that there has to be some higher-level structure in the PMT stream than 'a single SID PMT package' ... they must be paired somehow ? What is the tool you use for your analysis ? Edited October 2, 2006 by reeh Quote Link to comment
Derrick Posted October 2, 2006 Share Posted October 2, 2006 Another thought, @ Derrick: The Another thought, @ Derrick: The lack of symmetry between TV3 and TCM makes me think that there has to be some higher-level structure in the PMT stream than 'a single SID PMT package' ... they must be paired somehow ? What is the tool you use for your analysis ?between TV3 and TCM makes me think that there has to be some higher-level structure in the PMT stream than 'a single SID PMT package' ... they must be paired somehow ? What is the tool you use for your analysis ? nope, no higher level or power is involved This is basic stuff from ISO 13818-1. Because of the "lack of symmetry" @Lars' explanation doesn't stand. There are no ts_packets with 2 sections... Quote Link to comment
reeh Posted October 2, 2006 Author Share Posted October 2, 2006 (edited) ... This is basic stuff from ISO 13818-1.... There are no ts_packets with 2 sections... You made me get and look into the 13818-1 document I did a capture of another few minutes of the multiplex and looked for PID 0x0101 transport-packages. You are right, they each contain exactly one PMT - alternating between SID 210 and 270 ... Still the lack of symmetry puzzles me. It must be some second order effect. On the other hand, the debug DBViewer, I am testing, runs smoothly Edited October 2, 2006 by reeh Quote Link to comment
Guest Lars_MQ Posted October 2, 2006 Share Posted October 2, 2006 Well then it must have been a lucky circumstance I could fix it based on a wrong assumption If you want to beat a dead horse, go on. For me the bug is closed unless reeh reports a problem. Quote Link to comment
reeh Posted October 2, 2006 Author Share Posted October 2, 2006 Well I am. indeed, a 'happy camper'. Thanks to Lars_MQ for fixing this so swiftly, and thanks to Derrick for his analysis work and support to a 'Newbie'. ... and thanks to the whole DVBViewer-team for making a program that I grow more and more happy with from day to day... Actually, this is the seventh TV/Mediacenter package I have tried - and by far the best. Quote Link to comment
deco Posted October 8, 2006 Share Posted October 8, 2006 (edited) 'Lebeck' posted the same problem concurrently with me yesterday in this forum - Topic: 'Viasat TV3'. He states that he has a ' FireDTV-C TV Tuner - BDA Driver Version: 4.2 - Firmware: 1.2.1'. He is also receiving from the Danish TDCkabelTV network. I cannot see if he has the proper CI/CAM equipment. I will ask in his thread ... (Answer was: YES, have CI/CAM - see below. Same problem. FireDTV ...) i also have same problem with TV3 and are using a FireDTV box, channel works fine in MCE, mytheatre and progdvb so it's a DVBViewer issue :/ i cannot test with my technotrend card since it's one of those models without bda drivers, but with that card and mytheatre TV3 is also fine. -Deco Edited October 14, 2006 by Griga Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.