Jump to content

DVB Viewer cant play it's own recordings


improwise

Recommended Posts

I have a very weird problem, when I choose to make recordings in TS format, the actual recordings work fine, but quite often, DVBViewer cant play them. Now, the weird stuff here is that something like 2 out of 3 recordings play find, with audio and video, but about 1/3 doesnt have audio but video, or video but no audio. Now, you might think "bad recordings" but the fact is that ALL other players I have tried can play the files, so the files themselves can't be faulty. And since DVBViewer can actualy play 2 out of 3 recordings, I don't see any reason to suspect either the codecs or the configuration of DVBViewer, as that has not changed from recording to recording. And as mentioned about, the recordings do work in all other players. If I record in MPEG format, it seems to always work though. Have tried changing codecs back and forth but that doesnt seem to make any differene.

 

Any idea? This if far from a new problem, in fact, I have had it for perhaps 1-2 years now, but it's getting very frustrating now.

support.zip

Edited by improwise
Link to comment

 

You are right, that actually worked! But, how come every other player than DVBViewer seem to be able to handle this, but not DVBViewer? Your software is great to have, but it's still an extra step to take, and if you have to do it for more than 1/3 of the recordings, it is probably quite frustrating to do in the long run (although I apprechiate you takin the time to make this software, dont missunderstand me here please).

Link to comment
But, how come every other player than DVBViewer seem to be able to handle this

Every kind of stream handling has advantages and disadvantages. DVBiever can play TS files that others can't play.

 

If you want some other component to take over TS stream handling, make sure that a good TS demultiplexer/splitter is installed (e.g. Haali Splitter or Elecard Demultiplexer), untick Options -> DirectX -> Use DVBViewer Filter for TS, and then you'll see...

 

You may want to try a plugin that is able to patch the stream before it is recorded, but it's still in an experimental stage. See here:

 

http://www.DVBViewer.info/forum/index.php?...st&p=249793

 

Proceed as follows:

 

1) Use DVBViewer Pro 4.2.1, otherwise it won't work.

 

2) Install the plugin as described in the plugin description.

 

3) Export all affected (encrypted) channels that you want to record to INI files. You may use the DVBViewer channel editor, or for convenience, because it supports multi-selection, TransEdit 3.4.x from the members area: Rescan your DVB-C channels, select the ones that you want and click "Export to File" in order to export them to a single INI file.

 

4) Use a text editor to insert the lines

 

[Patch]

PatchType=ScrambledFlag

 

in the INI file(s).

 

5) Change the file extension from .ini to .patch and store the file(s) in the DVBViewer configuration folder, as desribed in the plugin description.

 

6) Let me know if it works. Nobody has tried this patch type up to now... ;)

Link to comment
Every kind of stream handling has advantages and disadvantages. DVBiever can play TS files that others can't play.

 

If you want some other component to take over TS stream handling, make sure that a good TS demultiplexer/splitter is installed (e.g. Haali Splitter or Elecard Demultiplexer), untick Options -> DirectX -> Use DVBViewer Filter for TS, and

 

I can't seem to find the setting your describe under Optins => DirectX?

 

I'm hoping to be able to play TS files recorded by DVBViewer in DVBViewer, without having to did down to much into the technical details of this. Somehow I can't really see that as a very odd requirement, especially since all other players seem to be able to handle the files without any problems...

Link to comment

Don' forget: The source of the trouble is your CAM, not DVBViewer. Only very few people are encountering this problem. So there is no need to change the stream detection handling in a way that entails the risk of other (partly unpredictable) issues. Try to look a bit beyond your own nose...

 

If something is done in DVBViewer, it will be rather in the recorder engine, but before we do that we need to know if the StreamPatcher plugin is a suitable remedy. With other words: Testers wanted... none of the developers or dedicated DVBViewer beta testers can do it, because none of them is encountering this issue.

 

So insist on a consumer's point of view - this would be the end of the discussion, at least from my side - or contribute as a member of the DVBViewer community. It's your choice...

Link to comment
Don' forget: The source of the trouble is your CAM, not DVBViewer. Only very few people are encountering this problem. So there is no need to change the stream detection handling in a way that entails the risk of other (partly unpredictable) issues. Try to look a bit beyond your own nose...

 

For what it is worth, I have tried several different CAMs from at least 2 different vendors, and with different version numbers, but the problem still remains. It could also be noted that I also have MediaPortal installed, which use the same devies and CAMs to make recording, and it has never encountered this problem. Also, when I tell DVBViewer to record in MPEG, the problem doesnt show up either...

 

Not at all intending to offend anyone here, but I still find it strange that every player besides DVBViewer seem to be able to play these files. There might be a good explaination for this, but this is still my opinion, and should count as that, nothing more, nothing less. Unfortunately, I neither have the time or knowledge to do what you ask of me, doesn't even know what a StreamPatcher plug-in is. I have many skills but video playback and the debugging of it just isn't one of them, sorry!

Link to comment

Seriously, is there really no fix for this? I must have tried almost every other TS player on the planet and they can all play the TS files, the only program which cant play them is the one which has created them. Also, I choose to make my recordings in MPEG, this problem does not occur, isn't that a bit strange if it is supposed to be due to a "lazy CAM". At least 80% of my recordings require the uses of Grigas excellent program to be playable by DVBViewer, while they can be played without problem with all other players without modification. Please forgive my ignorance here, but I just cant see how this could be due to a faulty CAM, especially since MediaPortal has not problem at all making recordings in TS format with the same hardware.

 

I had a look at the threads about StreamPatcher but is just way to complicated for me, and it also talks about channels I don't have (not sure what the impact of that is). Also, the "Options -> DirectX -> Use DVBViewer Filter for TS" mentioned above does not exist in my installation, at least not under DirectX, so I really dont know what to do here.

Edited by improwise
Link to comment

I have this issue as well. When changing to .mpg output format instead i got problem again with screwed up file index...pretty much the problem with the .ts container. DVBViewer must be extra sensitive to these indexissues because my .ts file is also playable with every other TS player besides DVBViewer and TSPlayer (DVBViewer made). I'm hoping i can setup Grigas suggestion on solution in this thread to see if this has any impact on the problem.

Link to comment

Well, i successfully applied the stream patcher plugin. It is ticked when checking plugins on every encrypted channel i have. Now, lets see if this is working. I will be testing it for a week or so and see if more recordings gets screwed up when using the .ts output format.

Link to comment

Recorded 25 shows with the stream patcher plugin applied and not one failed. Each and everyone was playable with both DVBViewer and TSPlayer. It works perfect. This would be great to integrate into DVBViewer somehow...if its possible of course.

Link to comment

Thanks for feedback. Good to know that it works.

 

I've already proposed to integrate this kind of patching in the DVBViewer Pro recording engine... we'll see if it will be picked up.

 

Another solution would be a plugin that performs the patching for all encrypted channels without having to create patch files. However, installing such a plugin in a way that covers background recordings will still be a bit awkward, particularly for unexperienced users :angry:

Link to comment
  • 1 month later...

What a disappointment! Your proposition about integrating this kind of patching in the DVBViewer Pro recording engine did pass by unheard by the bosses. Not a word about a fix/add for this issue on the 4.3 beta changelog. I really think this is an issue you should reconsider fixing in the 4.3 beta. Not so good for the DVBViewer reputation if 100% of its recordings are playable in every other player supporting .ts format, BUT only 75% with the DVBViewer itself (without the streampatcher plugin installed). Somewhat ironic!!! This even though you are saying not so many users suffers from the lazy cam issue.

Edited by majstang
Link to comment

Did some recording testing with DVBViewer 4.3 BETA and was surprised why i didnt get any corrupted recordings (.ts) when i use manual recording. Out of 20 recordings non were corrupted. I came to the conclution this only occurs when using timer recording. Out of 20 recordings i got 8 corrupted ones. Some had only sound and some had only video. Two werent playable with DVBViewer at all. Everyone of the corrupted recordings were playable with MPCHC. Please do something about this now when you have the chance and you even have Grigas cure for it. And stop blaming this issue on lazy cams...

Link to comment

Hi Thorsten!

 

Well, my German isnt that good im afraid but i understand enough to see you are suffering from a similar problem as i do. Please try out Grigas Stream Patcher plugin to see if your problems goes away. This plugin worked really well for me, but it is somewhat akward to install. Would be great if Lars and Chistian could see the need to integrate Grigas streampatcher into the recording engine...cuz something in it is very wrong when creating timer recorded .ts file format. It seem to screw up the index of the file (timestamps you are talking about) in 1 out of 3 recordings for me.

Edited by majstang
Link to comment

Hi majstang,

 

here's the translation of the post I was referring to:

 

For some recordings only the first few seconds of the recording are shown, then the playback stops suddenly. There's no audio during this playback.

In order to resolve the problem I tried playing the file using different software (Windows: VLC, Linux: VLC, Kaffeine, Video-Player, and mplayer). The only player which managed to play the file successfully was mplayer.

My next attempt was to use "ProjectX" to demux the file. Here's a short extract from the log-file:

 

!> last video PTS ends before the start PTS of this stream! Sync impossible

-> !! video & audio PTS doesn't match at any time!

-> adjusting audio at its own timeline

-> src_audio: MPEG-1, Layer2, 48000Hz, stereo, 192kbps, CRC @ 00:00:00.000

audio frames: wri/pre/skip/ins/add 376/0/0/0/0 @ 00:00:09.024 done...

-> we have 2 warnings/errors.

 

I assume that there is a problem with the timestamps of the video-file. How can this happen while writing the recording to disk? Are the data received being processed by an encoder or filter or the like? Or are they "only" rearranged in order to create a certain container structure? Could this be the origin of the problem?

 

Errors due to bad reception are nearly impossible since we've got a big, well aligned antenna.

 

cheers,

Thorsten

Link to comment

Yes, this is without a doubt the same bug we are talking about!

Try to install the Stream Patcher plugin. It would be intresting to know if it works for you as well.

http://www.DVBViewer.info/forum/index.php?...st&p=255749

 

It is somewhat akward to install and that is why my agenda is to have the DVBViewer folks to integrate something similar into the recording engine to prevent corruption of the .ts container that occurs today. They seem to be afraid this would be effecting other things in the DVBViewer application. Otherwise it had already been integrated in the 4.3 BETA. Quite understandable of course, but why else is there BETAs other than to try out new functions/feautures and ironing out the unexpected effects they bring in the overall picture?

Link to comment
Are the data received being processed by an encoder or filter or the like? Or are they "only" rearranged in order to create a certain container structure?

Depends on the recording format. In case of TS the timestamps are recorded as received. In case of MPG an offset is subtracted in order to let the timestamps start close to 0. Furthermore the MPG (program stream) recorder tries to handle timestamp discontinuities.

Link to comment

At the moment, I always use MPG as the recording format.

So there's definitely something wrong with the program-stream recorder!

Either there's a bug in the calculation of the amount of the offset or in the handling of timestamp discontinuities.

 

@majstang: I'm not quite sure if it is the same bug, since you are using the TS-format.

 

cheers,

Thorsten

Link to comment
@majstang: I'm not quite sure if it is the same bug, since you are using the TS-format.

I had similar problems with the MPG format as well from DVBViewer 4.1 and forward, so im quite sure we are on the same page. Grigas stream patcher should work for MPG as well, cuz it patches the stream before its recorded or am i wrong here?

Link to comment
So there's definitely something wrong with the program-stream recorder!

Rather a follow-up issue. All MPG recordings that I've tested here under different circumstances were ok. Discussing such assumed "bugs" is useless without knowing all relevant conditions (DVBViewer Version? Recording Service? Scheduled recording? DVB device? Which channel? CI/CAM involved? etc).

Link to comment

Ok, sorry. It should read: There could be something wrong with the program-stream recorder! ;-)

 

There's no CI/CAM involved at all.

 

Here's the the support.zip

support.zip

 

Thanks and cheers,

Thorsten

Edited by Warp10
Link to comment
  • 2 weeks later...

Ok, let's come back to it.

 

TT-budget S2-3200 (BDA)

TT devices/drivers are known to deliver corrupted "chaotic" data for a short time right after initialization. So if starting a recording requires initializing the device (usually in case of a scheduled recording, if the device is not used yet), the PS recorder engine may get confused by it. Or with other words: It shouldn't happen if DVBViewer is already playing the "to-be-recorded" channel.

 

That's what I mean by "follow-up issue".

Link to comment

I've run some tests:

 

DVBViewer Pro 4.2.1, TechnoTrend 3600 USB, 8 short scheduled MPG recordings from different Astra 19° East channels (including all audio tracks, no CI involved) with one minute pause in between, playback disabled causing DVBViewer to initialize and release the TT 3600 for each recording.

 

Most of the recorder logs showed one or two errors at the beginning, as I expected (see above). However, all recordings were playable in DVBViewer, and ProjectX could demux them without any problems.

 

MPG recordings start with a certain (random) delay because the recorder waits for a MPEG2 sequence header to appear in the stream (a program stream should start with a MPEG2 sequence header), so it looks like the early errors / discontinuities in the stream didn't affect my recordings at all. Conceivably, initial disturbances after the recording has actually been startet could mess up a program stream in the described way. Unfortunately I can't reproduce it, giving me no opportunity to analyse such an event and to consider ways to make the recorder more robust. I'll repeat the test later, maybe I'm lucky next time :)

Link to comment

Hi Griga,

 

thanks for digging into the problem.

If I remember correctly, you're absolutely right: All of the recordings having issues were scheduled, i.e. the computer was in hibernation and resumed using the Task Scheduler.

 

So kind of a workaround would be to create a timer to tune the channel shortly before the actual recording timer?

 

Hopefully either you'll find a solution or Technotrend will develop nicer drivers

 

cheers,

Thorsten

Link to comment
...consider ways to make the recorder more robust.

 

So kind of a workaround would be to create a timer to tune the channel shortly before the actual recording timer?

 

Hello guys!

 

As i have understood it this is exactly what the Stream Patcher plugin does...why invent the wheel all over again when the solution is already present?

 

@Griga could you explain to us newbies if you see it in an another way?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...