magilbert6 Posted November 3, 2008 Share Posted November 3, 2008 Hi, I have been recently experiencing strange issues with recording Ts and watching recordings in DVBViewer. Since 2 weeks, ts files recorded by dvbv can not be read correctly using dvbsource and i need to uncheck the option "use dvbsource for mpeg" to read my recordings. The problem is that I can not access subtitles doing that. I tried to upgrade dvbsource to the last beta, but that did not change anything. Do you have an idea of what could generate that behaviour? Best Regards. DVBV 3.9.4.0 DVBSource 3.2.2.0 Quote Link to comment
magilbert6 Posted November 3, 2008 Author Share Posted November 3, 2008 Here is the support stuff if needed...support.zip Quote Link to comment
Griga Posted November 4, 2008 Share Posted November 4, 2008 Since 2 weeks, ts files recorded by dvbv can not be read correctly using dvbsource What do you mean by "can not be read correctly"? Please describe it more detailed. Quote Link to comment
magilbert6 Posted November 4, 2008 Author Share Posted November 4, 2008 What do you mean by "can not be read correctly"? Please describe it more detailed. Black screen and no sound ... A bit like if the graph failed to initialize. Quote Link to comment
Griga Posted November 4, 2008 Share Posted November 4, 2008 What do you see on the DVBViewer Filter property page (View -> Filters -> DVB Source)? Provide a screenshot. Quote Link to comment
magilbert6 Posted November 4, 2008 Author Share Posted November 4, 2008 Thank you for your support. I tried to provide you with the screenshot, and noticed that whatever the choice for 'use dvbsource for mpeg" some recent recordings were always read with Halli splitter. The only thing I noticed different in those recordings is that they have been made with all audio channels (recorder->all audio tracks was ticked). I made some new recordings with only one audio and dvbsource is working again on it with subtitles . I remember now having ticked this option sometime ago... Is it a limitation of dvbsource when managing multiple audio tracks, or maybe some specific filters are missing on my machine? BTW for the black screen with dvbsource, It was only occuring when I unregistered Halli splitter for testing purpose yesterday (I guess that considering what I said before probably that something was going wrong in the graph). Best Regards. Quote Link to comment
Griga Posted November 4, 2008 Share Posted November 4, 2008 Is it a limitation of dvbsource when managing multiple audio tracks, No. What kind of recordings? From HDTV channels? Encrypted channels? Maybe the first MBs of the recorded files are corrupted for some reason, so that the DVBViewer stream detection doesn't find anything... in this case DVBViewer would delegate playback to the DirectShow GraphBuilder, that uses the Haali Splitter. Try TSPlayer from the members area -> tools section. It (only) uses the DVBViewer Filter for playback. If it doesn't work, increase Settings -> Search Depth. Quote Link to comment
magilbert6 Posted November 5, 2008 Author Share Posted November 5, 2008 (edited) Thank you Griga, this is some recordings of MPEG2 encrypted channels. I tried to use Tsplayer, again it plays fine my recordings with only one audio and fail to read the one with two audio. The result is black screen, and progress through the file is very fast (approx 100 MB/sec). I tried to increase the search depth till 400Mb by step of 50MB without success. Edited November 5, 2008 by magilbert6 Quote Link to comment
Griga Posted November 5, 2008 Share Posted November 5, 2008 Does TSPlayer detect the contained streams? The content of the file (or most of it) is still scrambled, I guess, so it can't be played. Seems when recording two or more audio tracks, descrambling doesn't take place. Maybe your CI/CAM can't handle it. Quote Link to comment
magilbert6 Posted November 5, 2008 Author Share Posted November 5, 2008 Does TSPlayer detect the contained streams? It detects one teletext stream, and nothing more. The content of the file (or most of it) is still scrambled, I guess, so it can't be played. Seems when recording two or more audio tracks, descrambling doesn't take place. Maybe your CI/CAM can't handle it. Still the file can be read in DVBViewer using Halli media splitter (both audio tracks available, but no subtitles), and I tried to play it succesfully in media player classic. Anyway I can leave with this tiny issue without any problem , however if you are still interested in investigating this, feel free to ask some new tests or data, Thank you Griga. Quote Link to comment
Griga Posted November 5, 2008 Share Posted November 5, 2008 Another theory: maybe the content is not encrypted, but the bits in the TS headers signaling encryption are still set. This would let the DVBViewer / TSPlayer stream detection reject them altogether, in contrast to Haali that doesn't care. I could check it if you would upload 1 MB from the file somewhere. Quote Link to comment
magilbert6 Posted November 6, 2008 Author Share Posted November 6, 2008 (edited) Another theory: maybe the content is not encrypted, but the bits in the TS headers signaling encryption are still set. This would let the DVBViewer / TSPlayer stream detection reject them altogether, in contrast to Haali that doesn't care. I could check it if you would upload 1 MB from the file somewhere. I uploaded the beginning of the file here. I checked also that on this reduced version DVBViewer acts the same... Edited November 6, 2008 by Griga Faulty download link Quote Link to comment
Griga Posted November 6, 2008 Share Posted November 6, 2008 Ok, after fighting a bit with the download link... The beginning of the file contains TS data packets that are (still) encrypted, but the transport_scrambling_control bits are reset. So DVBViewer assumes that the data is unencrypted, tries to read it, doesn't find anything usable, gets to the conclusion that the video and audio PIDs refer to unknown stream types and stops analyzing the streams, thus missing the unencrypted packets following later. In a nutshell: The recording is faulty, most likely due to the CI/CAM. If data is encrypted, the transport_scrambling_control bits must be set. Removing the first MB or so would fix it. After a slight change in the TSPlayer code it was able to play the sample. However, that only treats the symptom, not the cause of the trouble, and I have to investigate which other problems may result from this change. So better don't rely on it... Quote Link to comment
magilbert6 Posted November 7, 2008 Author Share Posted November 7, 2008 The beginning of the file contains TS data packets that are (still) encrypted, but the transport_scrambling_control bits are reset. So DVBViewer assumes that the data is unencrypted, tries to read it, doesn't find anything usable, gets to the conclusion that the video and audio PIDs refer to unknown stream types and stops analyzing the streams, thus missing the unencrypted packets following later. In a nutshell: The recording is faulty, most likely due to the CI/CAM. If data is encrypted, the transport_scrambling_control bits must be set. Removing the first MB or so would fix it. Ok thank you Griga, editing my file did the trick. I investigated a little more what was the conditions to generate faulty files. - recordings coming from the timer to automatically run DVBViewer are always faulty (computer is not in stand-by or hybernation mode) - When I record directly a channel that I watch, sometimes it's faultly and sometime It is not... I have a TT S2 3200 + CI + POWERCAM + official french canalsat provider card Do you have some ideas I could test to avoid this? 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.