Jump to content

DVBViewer 5.0 Unicast discontinuities


majstang

Recommended Posts

There is definitely a bug introduced in the DVBViewer 5.0 Unicast device. One hour of watching a HD channel gives approximately 70 discontinuities. Reverting to DVBViewer 4.9.6.20 with same settings and watching one hour gives 3 discontinuities. The difference can be traced in the DVB Source. Significant for DVBViewer 5.0 is an unusual high

number of queued video buffers. The figure reaches nearly the number of allocated buffers. The behaviour for DVBV 4.9.6.20 is the opposite, the number of queued video buffers hardly ever exceedes zero. Allocated buffers for 4.9.6.20 are also much lower (24 compared to DVBV 5.0 of 210). The whole thing is quite annoying and I'm now forced to abandon DVBV 5.0 completely.

Using RS 1.23.1 when testing both DVBV version installed on the same PC as RS. According to the changelog of DVBV 5.0 the only thing changed for the unicast device is:

Fix: Unicast Devices: Problems with auto retune fixed.

Don't know if the auto retune fix can cause such issues or what is does really?

 

Using the RTSP device is still out of question. The discontinuities here are massive and watching a HD show long enough it's painfully apparent the discontinuities are in fact video and audio going out of sync. Haven't investigated the possibility the issue could be router related yet, but that would be the logical end to start tinkering.

Link to comment

Have you tried the RTSP device with TCP?

Hi Tjod!

I think your question was directed to me and not Mr.Omnium. Yes i've tried the RTSP device with TCP also. The results are the same, the discontinuities wont go away no matter of TCP or UDP. When using the RTSP device the stats in DVB Source are different. When timings between video and audio gets too much out of sync (over a second) DVBV 5.0 does an auto retune and logs it as "Last Error: Graph too late (1)". After the auto retune all other stats gets resetted. It's like if something in between RS and client are hindering the network traffic causing the out of sync. Using the unicast device the issue is not the same, no sync problems only much more discontinuities on the DVBV 5.0 compared to DVBV 4.9.6.20.

Link to comment

majstang,

 

You may have tried this already but I was able to eliminate my graph too late problems by playing with the latency and max queued audio values in the DVBSource window. I am running RTSP/UDP but the client and service are running on the same computer.

 

I have 0 discontinuities after 45 minutes of CMore First HD (Satellite), Queued video buffers is in the range of 130 - 195, Allocated 241.

 

You situation sounds like it's different to mine so maybe this doesn't help anyway.

Link to comment

I'll look into it a bit more but I've noticed that HD channels stutter and SD channels flicker, using either type of device, in DVBViewer 5.0.

 

I've tried lots of different things to reduce it - it seems much worse in D3d Exclusive mode - but I can't eliminate it.

 

I was going to switch back to v4.9.x but will collect some data and post it here for you.

 

I also have XBMC and the TV plugin for DVBViewer and recordings that flicker and stutter in DVBViewer play fine in XBMC.

Link to comment
I also have XBMC and the TV plugin for DVBViewer and recordings that flicker and stutter in DVBViewer play fine in XBMC.

.

Also noticed that the flickering in SD channels is much more pronounced when the OSD is displayed on screen.

same to me and the last 'Problem' is very old. Edited by omnium
Link to comment

majstang,

 

You may have tried this already but I was able to eliminate my graph too late problems by playing with the latency and max queued audio values in the DVBSource window. I am running RTSP/UDP but the client and service are running on the same computer.

 

I have 0 discontinuities after 45 minutes of CMore First HD (Satellite), Queued video buffers is in the range of 130 - 195, Allocated 241.

 

You situation sounds like it's different to mine so maybe this doesn't help anyway.

entrecour,

 

thanks for sharing your experience. Unfortunately you're right my situation seem to be different from yours. Have been trying pretty much every combination of latency and queued audio values, but can't shake the graph too late issue :bye:

Link to comment

Tüftler and Derrick,

 

I'm happy it works for you. However that doesn't mean the unicast and RTSP devices necessarily are problem free. When the development of DVBViewer takes a turn for the worse it's time to speak up. I don't know which factor in the devices are causing my issues, but it sure would be nice to get to know that. With old DVBV the discontinuities frequency was acceptable, but it is now getting completely out of hand. I have some questions for you regarding patterns I can't explain. Testing done with RS 1.23.1, DVBV 5.0, DVBV 4.9.6.20 installed on the same PC.

 

1. When RS records a HD show without DVBViewer running in background the discontinuities are always 0. Why?

 

2. When RS records a HD show and in the same time streams to DVBV 4.9.6.20 with the unicast device I get approximately 9 discontinuities per hour. I can't figure out why? RS controls the tuner and how can the unicast device interfer with the data being written by the recording engine?

 

3. When RS records a HD show and in the same time streams to DVBV 5.0 with the unicast device I get approximately 70 discontinuities per hour. Same question the unicast device interfers even more with the data being written by the recording engine?

 

4. When RS records a HD show and in the same time streams to DVBV 5.0 with the RTSP device I get approximately 200-300 discontinuities per hour. The recording is completely unwatchable. Every little discontinuitie and graph too late error is embedded into the recording.

 

Only conlclusion one can draw is something is very wrong :whistle:

Link to comment
  • 2 weeks later...

Had a sitdown to figure out why recent changes in the unicast device causes so much more discontinuities and why the RTSP device is completely unusable on my HTPC system. I knew early versions of DVBViewer/RS both my FloppyDTV-C cards has been working flawless. About two years ago I started to see a few discontinuities with that DVBViewer/RS version and posted a bug report. That report didn't lead anywhere. With DVBViewer 5.0 even more discontinuities and a system on the verge of being unusable.

 

After heavy testing with different antenna splitters and cables back and forward nothing could fix the discontinuities.

Not until disabeling the FloppyDTV-C tuners completely and disconnecting them from antenna, I had a breakthrough. Using my two BlackGold BGT3620 DVB-T/C tuners only all discontinuities using the unicast device disappeared and the severe problems with the RTSP device also disappeard. Not one single discontinuitie or graph too late error ever since. Very encouraging in a way, but not in other perspectives.

 

My only choice seem to be sending my FloppyDTV-C tuners into retirement. Would be interesting to know what changes DVBViewer development has taken to result in such issues. Or perhaps my tuners are faulty, which seems far fetched because there's a so significant difference in the amount of discontinuities comparing DVBV 4.9.6.20 and DVBV 5.0. And not to speak about the RTSP device working very poor with FloppyDTV-C tuners. I believe not many users are still using Floppy- and FireDTV tuners any longer and that should be the answer upon why not many other users have been reporting about these errors. If my conclusion is correct and old tuners no longer are fully compatible with DVBViewer that development direction is ominous, especially if no notice is given.

Link to comment
If my conclusion is correct and old tuners no longer are fully compatible with DVBViewer that development direction is ominous, especially if no notice is given.

bollocks.. I still use a firedtv-s2 cos it's my only device with CI. Discontinuties: none :biggrin:

Link to comment

An insightful Derrick answer as usual..not helping one bit ;)

What differs is Im not using any CI in my FloppyDTVs, but the other solution. I wouldnt be surprised if the issue can be pinpointed to hardware framework and the plugin API. How else explain why newer tuners works perfect and older not?

Link to comment

majstang,

 

Sorry to hear that you are still having discontinuity problems. I am still using a Firedtv tuner with no discontinuities.

 

In fact I would say my experience has improved significantly over the last 12 / 18 months but I put that largely down to improvements in LAV, and tweaking DVBSource parameters although I haven't tested with older versions of DVBViewer to see is that assumption is correct. I used to have big problems with high (30000) symbol rate HD channels on Thor but not anymore.

 

By the way what is the FloppyDTV driver version that you are using? I am on 5.0.6326.3001. Are you using the latest firmware? The only place I think you can get these now is on Tystpc.

 

FYI I have attached a screen shot of the DVBsource window.

 

post-53593-0-93820200-1358608932_thumb.jpg

Link to comment

Hi entrecour!

 

Now that is juicy information :biggrin:

I have the last driver Digital Everywhere released before closing down. Wasnt aware the driver development continued after that. Checking driver version i have 5.0.6070.3000 from 2009-03-12 (Win7 compatible). I have a look at it and will be doing some updating and then hopefully my issue could be fixed. Let you know.

Many thanks

majstang :bye:

Link to comment

By the way what is the FloppyDTV driver version that you are using? I am on 5.0.6326.3001. Are you using the latest firmware? The only place I think you can get these now is on Tystpc.

Hmm, that was strange! The driver you linked to on tystpc is the same I had installed before:

http://tystpc.nu/downloads/de/091128_firedtv_setup_5_7.zip

But when uninstalling and reinstalling it it gets version number 5.0.6070.3000 as before and not the one you have. I did install the BDA driver for Win7 x86 systems. Do you have any later driver than:

Date: 28. November 2009

Setup Version: 5.7

Supported Hardware : All FireDTV und FloppyDTV Versions

Supported OS : Windows XP SP2, WinMCE 2005, Vista (32/64 Bit) Windows 7 ( 32/64Bit)

?

Link to comment

The version I am using is dated 23/11/2009 - that's the date from the driver tab of Device Manger, that's where I also got the driver version from. There may even be a later one - I saw a reference to that possibility here but the link provided was dead. If you manage to get hold of it let me know.

 

:bye:

Edited by entrecour
Link to comment

Entrecour,

bad news. It seems I have the latest driver installed. What threw me was a mistake seemingly done by Digital Everywhere. Checking FireDTV driver version 5.6:

- Latest filechange on the DVB-C driver .sys and .inf file was made 2009-03-12

- Reading the DVB-C driver .inf confirms that date

 

FireDTV driver version 5.7 (the latest one):

- Latest filechange on the DVB-C driver . sys and .inf file was made 2009-12-23

- Reading the DVB-C driver .inf they haven't changed the date. It's still 2009-03-12 and it's that .inf information that shows up in the Device Manager.

 

Same mistake wasn't done with the FireDTV-S2 driver. However the date you are seeing in the Device Manager does not add up with the .inf date found for the 5.7 FireDTV-S2 BDA Win7 x86 driver, so you must have a later driver. Not so sure the same could be found for FireDTV-C. All searches on Google gives nada :(

 

It seems the simplest solution would be to retire the FloppyDTVs for good, since my two dual-tuner BlackGolds works flawless.

:bye:

Link to comment

An insightful Derrick answer as usual..not helping one bit ;)

What differs is Im not using any CI in my FloppyDTVs, but the other solution. I wouldnt be surprised if the issue can be pinpointed to hardware framework and the plugin API. How else explain why newer tuners works perfect and older not?

..again, what has the hardware device with or without CI to do with you problem?? Take transedit and monitor the mux.

Link to comment

Well, the problem seem to be complex and I do not have enough detailed knowledge about how hardware framework and plugin API works together. The only guy here abled to analyze it correctly doesn't seem to be interested, so I'm not sure I wanna chase this issue any further. The issue also borders a topic not allowed to discuss in here.

 

These are the facts if having the FloppyDTV-C tuners connected:

1. When RS records the discontinuities/error shows up (in the RS log file) as long as RS streams to a DVBViewer client.

2. If no client is connected to RS while recording, the recordings never has any errors/discontinuities.

 

Number 2 implies the FloppyDTV-C recieves the dvb stream ok and are decrypted ok, without the discontinuities. When starting a client the RS streamserver should put through the already decrypted stream to the unicast device and client. What i don't understand is, how can RS to client streaming suddenly affect what's being recorded, cuz now all errors/discontinuities shows up in the finished recording? My theory is the discontinuities are in fact decryption interference, caused by the client. I have difficulties to explain it otherwise, cuz if it were decoder related the errors/discontinuities never would have showed up in the finished recording. In that case the discontinuities only would have been visible in the client and not interfere with what's being written by the recording engine.

 

If using the plugin descramble method the plugin API gets called, which probably never get initialized if using a CI. I can imagine the hardware framework constitutes instructions on how to correctly call the plugin API. If the instructions are changed for a tuner brand the API call goes wrong. That could also explain why it works as it should with my newer tuners and not with my FloppyDTV-C tuners and also why the issue have gotten progressively worse...from non existent 2 years ago to a few discontinuities with DVBV 4.6 to 4.9.6.20 and massive discontinuities with DVBV 5.0.

 

But as said this is only guessing and theories. I'm happy it works ok with my BlackGold tuners, the FloppyDTVs are getting very old and it's time to let them go. Still think there's a large bug in there somewhere.

Link to comment

@majstang, I don't follow your theory, though I never deny or exclude possible bugs in dvbv or rs. But referring to your statement "..old tuners no longer are fully compatible with DVBViewer.." I only can reiterate bollocks :bye:

Link to comment

@majstang, I don't follow your theory, though I never deny or exclude possible bugs in dvbv or rs. But referring to your statement "..old tuners no longer are fully compatible with DVBViewer.." I only can reiterate bollocks :bye:

Oh man, I rest my case :rolleyes: Lars, where are you :lol:

Link to comment
  • 2 weeks later...

set the Recordingservice priority to 'realtime:24/high:13'. That helps in my enviroment, all discontinuities are gone and all bug reports in this respect, makes now sense to me...but I don't like this workaround. I prefer an independent/standalone Recordingservice written in assembly language.

 

hth,

omnium

 

--

The storm in the teacup is over.

Edited by omnium
Link to comment

No, this issue could not be CPU induced, cuz if it were I would have seen the same errors/discontinuities using my Blackgold tuners alone and I am not. So regardless of RS priority the issue appears only if activating my FloppyDTVs and start streaming from RS to a DVBViewer client.

 

The problem must be linked to the hardware framework. There is no other possible explanation since one tuner brand has the issue and my other tuner brand has not. Lars changed something in the first DVBV 4.9.9.x beta, from there and on the problems went from "acceptable and not so annoying" to "really bad". I did post specific about the RTSP problems in that beta thread with support.zips, but the problem got ignored. Several changes in the hardware framework has also been made from RS 1.20. The plugin problems got so bad that RS 1.21.1 had to be released just to reset everything to "old" handling prior 1.20. Wondering if the reset really went well for my FloppyDTVs ;)

 

 

As said before everything works well with my Blackgolds though, so i`ll stick with them :bye:

Edited by majstang
Link to comment

No, this issue could not be CPU induced, cuz if it were I would have seen the same errors/discontinuities using my Blackgold tuners alone..

;) please think about critical timing/sync problems/other driver influenced tasks. The Blackgold Driver seems to be better...thats all. To be absolute sure, you have to reactivate your FloppyDTV and try it and I guess it will work. The Firewire Driver/Hardware will also be very essential..do you have any latency problems with it? Could be the reason why other user/mods don't have any problems with the FloppyDTV.

.

Perhaps you change your mind if you able to force discontinuities with your beloved Blackgold? Try to lower the Recordingservice priority eg. to 'idle:4' and I am sure you will see discontinuities. IMO, a good service/realtime program, may not act like that.

Edited by omnium
Link to comment
..from there and on the problems went from "acceptable and not so annoying" to "really bad".

..meaning it was never good. Only QEF is acceptable and that's what I got with my FireDTV-S2 and the latest RS :D

Link to comment

;) please think about critical timing/sync problems/other driver influenced tasks. The Blackgold Driver seems to be better...thats all. To be absolute sure, you have to reactivate your FloppyDTV and try it and I guess it will work. The Firewire Driver/Hardware will also be very essential..do you have any latency problems with it? Could be the reason why other user/mods don't have any problems with the FloppyDTV.

.

Perhaps you change your mind if you able to force discontinuities with your beloved Blackgold? Try to lower the Recordingservice priority eg. to 'idle:4' and I am sure you will see discontinuities. IMO, a good service/realtime program, may not act like that.

I can test when I get some free time, absolutely. I doubt it would yield any difference though. If it were driver related I wouldnt see such a significant difference in the amount of errors just by comparing when running DVBV 4.9.6.20 and DVBV 5.0. Also the errors in the recorded stream are non existent IF no client are connected to RS. If the errors would be signal related they would show up regardless a client running or not.

 

I will test the FloppyDTVs with CI as well, which probably will work flawless and also confirm my theory.

 

..meaning it was never good. Only QEF is acceptable and that's what I got with my FireDTV-S2 and the latest RS :biggrin

..for the past year and a half yes! It has been a few errors but that doesnt explain the sudden and massive increase with DVBV 5.0. The initial problem are described here:

http://www.DVBViewer.tv/forum/topic/46515-rs-1903-dvbserver-frame-dropping/

Link to comment
I can test when I get some free time, absolutely.
top!
If it were driver related I wouldnt see such a significant difference in the amount of errors just by comparing when running DVBV 4.9.6.20 and DVBV 5.0. Also the errors in the recorded stream are non existent IF no client are connected to RS.
..that is a confirmation and i can't find a discrepancy to my theory. Set the Client Priority to low and the Service Priority to high/realtime if they work on the same PC, and it will work like a charme...most of the time. The RS must/should be independent from the client, but it is not :(

 

shot3ybf7.jpg

RS serving three LiveTV-Clients at the same PC without any issues.

 

If the errors would be signal related
the errors/discontinuities are not signal relatetd.
I will test the FloppyDTVs with CI as well..
I am strained on it!

 

--

In the land of the blind, the one-eyed man is king.

[Desiderius Erasmus Roterodamus]

Edited by omnium
Link to comment

@Omnium,

I did test out the priority setting you suggested and unfortunately it didn't give any difference as far as the errors/artefacts goes that shows up in my recordings if having a client connected to RS (on the same system).

 

Test done with DVBV 5.0, latest RS and FloppyDTVs:

 

Unicast device - could not reduce the errors by tweaking the priority order for RS and client. Uplifting was when installing DVBV 5.0 over the DVBV 4.9.6.20 the errors was reduced to levels prior to 5.0. The errors in the recordings shows up when signal mysteriously drops for a short while from 100% to 24% and back to 100% again if client are connected (does not happen with the Blackgolds). No difference if using CI or plugins.

 

RTSP device - still totally unusable. 200-300 errors per hour regardless of using plugin method or using a CI, which unfortunately and undeniable busts my theory. Priority settings didnt yield any difference. Here the errors constitutes of both signal drops and graph too late errors which results in visible corruption of picture on DVBV screen.

 

It's hard to believe both my Floppy DTVs could be faulty, so perhaps the key to my problem could be the firewire part of things (at least it could explain the errors for the RTSP device). After all that is what differs compared to the Blackgolds (PCI-E). Don't think I will chase this any further since tracing the root cause takes too much time, which I don't have.

The FloppyDTVs will be heading for the scrap heap.

 

Thanks for your help :bye:

Link to comment
..so perhaps the key to my problem could be the firewire part of things (at least it could explain the errors for the RTSP device). After all that is what differs compared to the Blackgolds (PCI-E). Don't think I will chase this any further since tracing the root cause takes too much time, which I don't have..
..your decision...but checking the latency, is a very easy job and you will get certainty.

I stay with high priority for the RS (that is/was the goal in my enviroment)..as long as a new RS/DVBViewer occurs.

 

<edit>

no changes with RS 1.24 / DVBViewer Filter 3.7.0

</edit>

Edited by omnium
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...