RS 1.27 Hard crashes

[majstang]

I had two hard crashes since updating to 1.27. Earlier RS versions was rock stable for me. It usually happens during wakeup from hibernation and using the RTSP device. RS goes unresponsive and if trying to restart RS icon stays grey no matter what. Only choice is a restart of system to get things working. Here's a bit of the svcdebuglog when things goes wrong between a hibernation and a wakeup:

 

31.10.13 15:29:09.186 TDataReaderRecordings Destroy

31.10.13 15:29:22.459 TRecordingEngine Standby PBT_APMSUSPEND

31.10.13 15:29:22.459 TRecordingEngine Setting next recording: 2013-10-31 16:51:00

31.10.13 15:29:22.459 ThdProc Enter

31.10.13 15:29:22.460 TUPnPAnnounce Stop

31.10.13 15:29:22.480 TRTSPUDPClient Release 7231 BDA DVBC Tuner (3)

31.10.13 15:29:22.480 TRTSPUDPClient Destroy 7231 BDA DVBC Tuner (3)

31.10.13 15:29:22.581 TRTSPUDPClient Destroyed 7231 BDA DVBC Tuner (3)

31.10.13 15:29:22.581 TRTSPUDPClient hamDeleted 7231 BDA DVBC Tuner (3)

31.10.13 15:29:22.581 ReleaseStandbyblock RTSP-Client 127.0.0.1

31.10.13 15:29:22.581 SetThreadExecutionState 0x80000000

31.10.13 15:29:22.581 TRecordingEngine Releasereference RTSP-Client 127.0.0.1: 0

31.10.13 15:35:04.512 TRecordingEngine Time changed

31.10.13 15:35:06.147 TRecordingEngine Resume PBT_APMRESUMEAUTOMATIC

31.10.13 15:35:06.147 TRecordingEngine Resume Processing...

31.10.13 15:35:06.147 TRecordingEngine fwakeup 0

31.10.13 15:35:06.147 ReleaseStandbyblock PBT_APMRESUMESUSPEND

31.10.13 15:35:06.147 SetThreadExecutionState 0x80000000

31.10.13 15:35:06.208 TRecordingEngine fwakeup do

31.10.13 15:35:06.208 TRecordingEngine NextEPGUpdate 1899-12-29

31.10.13 15:35:06.208 TUPnPAnnounce Start

31.10.13 15:35:06.209 TUPnPAnnounce InitWsocket 127.0.0.1

31.10.13 15:35:06.209 TRTSPWebserver Connect Could not connect 554

31.10.13 15:35:06.563 TRecordingEngine Resume PBT_APMRESUMESUSPEND

31.10.13 15:35:06.563 TRecordingEngine Resume Processing...

31.10.13 15:35:06.563 TRecordingEngine fwakeup -1

31.10.13 15:35:08.073 TRTSPUDPClient SendBufSizeUDP 13280000

31.10.13 15:35:08.073 SetStandbyblock RTS-Client127.0.0.1

31.10.13 15:35:08.073 SetThreadExecutionState 0x80000041

31.10.13 15:35:08.073 TRecordingEngine AddReference RTS-Client127.0.0.1: 1

31.10.13 15:35:08.073 TRTSPUDPClient SetTuner TType: 0, Freq: 370000, Symrate: 6875, LOF: 0, Tone: 0, Pol: 3, DiseqC: 3, FEC: 0, APID: 4356, VPID: 4100, PMT: 260, SID: 1064, SatMod: 0, DiseqCVal: 0, NID: 40999, Flags: 25

31.10.13 15:35:11.208 TBDAMedion Opendevice bvMedion

31.10.13 15:35:11.208 TRTSPUDPClient AllocateHardware 7231 BDA DVBC Tuner (3)

31.10.13 15:35:11.208 TRTSPUDPClient SetTuner got Hardware

31.10.13 15:35:11.208 TBDAMedion SetTuner TType: 0, Freq: 370000, Symrate: 6875, LOF: 0, Tone: 0, Pol: 3, DiseqC: 3, FEC: 0, APID: 4356, VPID: 4100, PMT: 260, SID: 1064, SatMod: 0, DiseqCVal: 0, NID: 40999, Flags: 25

31.10.13 15:35:11.507 TRTSPUDPClient SetTuner Set the tuner

31.10.13 15:35:11.507 TRTSPUDPClient pids 0

31.10.13 15:35:11.515 TRTSPUDPClient AddPid 4100,4356,0,260,7940

crashes here

 

The annoying thing after the crash is during the system restart Windows exit screen goes on forever until I lose patience and do a hard reboot. Will downgrade to 1.26.

[Griga]

Have you tried the tweaks that restore the RTSP buffering behaviour of previous versions?

 

http://www.DVBViewer.tv/forum/topic/19629-recording-service-beta/?p=395918

 

Tweaks for SAT>IP UDP and TCP send buffer size, specified as number of packets, each containing 1328 bytes (...) In case of problems you can set the values to 0 for restoring the behavior of previous versions.

[majstang]

Have you tried the tweaks that restore the RTSP buffering behaviour of previous versions?

 

http://www.DVBViewer.tv/forum/topic/19629-recording-service-beta/?p=395918

 

 

Oh, I didnt notice this tweak! Thanks Griga, ill try it and report back

[majstang]

20 days of silky smooth running of RS without any hard crashes We can now safely state that the SAT>IP UDP and TCP buffer size change was definitely the cause for RS suddenly begun behaving unstable. I take for granted this change will be removed in next build, even though not many folks seem to have reported the same troubles. Introducing settings that makes the system unstable can never be good, hard crashes should only be caused by faulty hardware and shifty drivers and not too large buffer sizes. Makes support of this kind of problems generally a bit harder if sticking with the current default SAT>IP UDP and TCP buffer size.

 

Regards

majstang

[Griga]

20 days of silky smooth running of RS without any hard crashes

 

After which tweak / change? Are you using RTSP / UDP or RTSP /TCP?

 

I take for granted this change will be removed in next build,

 

It won't be removed, because up to now you are the only one who reported severe trouble. It proved to be heavily advantageous on several PCs where it was tested. E.g. here it increases the maximum UDP data rate in a 100 MBit LAN from 40 MBit/s to more than 90 MBit/s. Other testers achieved similar or at least neutral results. The buffering was changed due to several complaints about data loss / discontinuities when using RTSP / UDP, even with data rates less than 15 MBit/s via LAN (which means with a single HD channel). The new buffering and transfer strategy (non-blocking instead of blocking) particularly avoids repercussions of network events on the DVB card driver. So for example if the Recording Service sends a channel to a client and records it at the same time, the recording won't be affected by network delays or a data jam.

 

The buffering takes place somewhere deep down in the Windows Sockets on kernel / driver level. The Recording Service uses the Winsock API to tell Windows which kind and extent of buffering shall be used. This is the most efficient way. However, the results depend on how well it is handled by the involved network devices and drivers (obviously not very well in your case ). That explains why the results can be different on different PCs, and that's why we provide the possibilty to adjust the buffering behaviour.

[majstang]

Thanks, for the in-depth background description, much appreciated I had to retire my old Floppy-DTV-C tuners because of these discontinuities you are talking about, when the RTSP-server was newly introduced. For some mysterious and thankful reason my two Blackgold tuners worked ok with RTSP, right away.

 

After which tweak / change? Are you using RTSP / UDP or RTSP /TCP?

 

The RTSP-server UDP tweak.

 

It won't be removed, because up to now you are the only one who reported severe trouble.

 

I didn't mean it should be removed, I just meant it can be problematic having the larger buffer size as default if it could lead to RS crashes. No problem, support wise we only have to remember that this thing also could result in RS crashes.

 

 

Another related topic. Ever since starting using the RTSP-server these logs always shows up during initialization of the WinSock /local network and connection to RTSP-server:

 

 

31.10.13 15:35:06.209 TUPnPAnnounce InitWsocket 127.0.0.1

31.10.13 15:35:06.209 TRTSPWebserver Connect Could not connect 554

 

My crashes with the larger buffer size always occured during wake-up of system (with client running when hibernated and also wake-up). Perhaps there's some network-driver issue on my system that is causing the crashes, I don't know. But then again these logs also shows up with buffer size zeroed out and RS is still stable. These logs has probably nothing to do with the crashes. However maybe there's a timings issue anyway? The Winsocket initialization and the connection to the RTSP-server occurs at the exact same time, which to me looks a bit strange. The 554 port is obviously closed when RS tries to connect to it. I don't know how fast reaction time the WinsocketAPI and the network driver has. Maybe a short delay between initialization and connection, 100ms or so could do wonders to get rid of the fishy log at least.

 

 

regards

majstang

Edited November 21, 2013 by majstang

[Griga]

The RTSP-server UDP tweak.

 

In which way? Set to 0?

 

Other values imply two changes: Non-blocking mode instead of blocking mode and a configurable buffer size set by the RS instead of the default 8 kB buffer size (which would be far too low for non-blocking mode).

 

The interesting question is if non-blocking mode or the increased buffer size.causes the crash in your case. You could try to lower the buffer size e.g. to 5000 or even 1000 packets, which proved to be sufficient in my setup. Maybe 10000 is far too much. We have to learn by experience...

 

The basic problem is that DVB data arrives in real time, which means, it is pushed into the PC. If it is not processed in time buffer overflows occur and data gets lost.

 

In blocking mode the send-to-network call doesn't return until the data can be transferred to a buffer. It will wait for free buffer space until a time-out occurs. So network delays may cause a buffer overflow in the BDA filter graph or BDA device driver, since the broadcasters don't wait. This is a kind of gamble because the buffering behaviour of BDA drivers is unknown and can't be influenced by the application.

 

In non-blocking mode the send call returns immediately in any case. If there is no free buffer space it returns with an error code, and it's up to the application to handle it. The RS will drop the data in this case without affecting the BDA filter graph and DVB device, so other activities depending on it (e.g. an ongoing recording) remain undisturbed. Of course the send buffer must be large enough to compensate all "normal" delays that may occur in a given network setup. That's why we have chosen such a high value as default.

[majstang]

In which way? Set to 0?

 

I did tweak it to 0 packets in order to restore the buffering and transfer strategy to the behavior of previous RS versions, which I now learnt restores the blocking mode and the default 8kB buffer size.

 

The interesting question is if the non-blocking mode or the increased buffer size.causes the crash in your case. You could try to lower the buffer size e.g. to 5000 or even 1000 packets, which proved to be sufficient in my setup. Maybe 10000 is far too much. We have to learn by experience...

 

I can't remember with certainty, but when tweaking the RTSP-server UDP for the first time I think it was set to an even bigger value of 20000. Yes, it's an interesting question and it seems that remains to be a hard one to find out, which one causes the crash. I'll tinker around with different buffer sizes to see where the stable threshold lies. It will of course take some time to get results, considering I only got two crashes on a 30 day period with the new non-blocking mode.

 

I don't know how common my user behaviour is regarding never closing down the DVBViewer client. I still think, since the crashes occured during RS and client resuming from hibernation (RS recording timer woke the PC) with no recordings going yet nor any broadcaster material have reached the client yet, there must be something problematic in the initialization and connection phase. The hard part for me is to understand how the non-blocking mode and larger buffer size could result in a crash when it's functionality haven't even kicked in yet?

[mch]

Hello Griga and majstang,

 

I have to report exactly the same problems as described by majstang.

 

I use DVBV Recording Service 1.27 for recording. After recordcording end the PC goes to sleep state and wake up before next recording. Once a day or two (max three) the RS stop works and only solution is hard reset of the computer!

 

Could you please explain me exactly the solution. Should I rollback to RS1.26 or make some tweeks?

 

If you will need any logs from me just tell me, I will do my best to find out the reason why it happens.

 

I have fresh instal of Win7 x64, Brand computer (HP 6200Pro SFF), 12GB RAM, 80GBSSD and 1TB HDD for recordings, Quadro 600 graphic card.

 

Thanks for investigation!

Edited November 28, 2013 by mch

[majstang]

Your crashes happens a bit too frequent to be caused by the non-blocking mode /large buffer size IMO. Was RS 1.26 stable for you?

Only a yes on that question can make a tweak attempt worthwhile. If no it's more likely faulty tuner hardware or shifty (tuner) drivers can explain your hard crashes.

 

The tweak you do like this:

-Close DVBViewer client

-Stop RS (rightclick RS systray icon and stop RS)

-In the DVBViewer folder you can find and start "RSTweaker.bat"

-Scroll down to "SAT>IP UDP send buffer size" if you are using UDP.

-Or scroll down to "SAT>IP TCP send buffer size" if you are using TCP.

-Change value to 0

-Hit the "Save" button and close tweaker

-Restart RS and DVBV client.

 

regards

majstang

Edited November 29, 2013 by majstang

[mch]

Is this usabel also for me if I use DVB-C ???

 

I have installed DVBV+RS1.27 freshly so I had no previous RS installed. I cant be sure if it will work better. I use Technisat Cablestar Combo HD CI USB tuner and I buyed it before two months... So I guess it is ok. About the driver I cant say, Technisat unfortunatelly doesnt offer more recent drivers

 

I heard that I could use some more recent drive version from Azurewave, so I am using this:

http://www.azurewave.com/driver/DigiTV3.4%20build019d_DVBData1.8.1.4_RTM_CD.rar

 

Could you recommend me others?

Edited December 1, 2013 by mch

[majstang]

Is this usabel also for me if I use DVB-C ???

 

I have installed DVBV+RS1.27 freshly so I had no previous RS installed. I cant be sure if it will work better. I use Technisat Cablestar Combo HD CI USB tuner and I buyed it before two months...

 

Hi mch!

Aha, then I guess there's no chance for you to test RS 1.26 if you haven't downloaded it earlier. The DVBViewer company doesn't provide previous versions of anything, despite masses of users asks for it. It's a pity IMHO.

 

I guess you haven't any choice but to try out the tweak. I would be surprised if that fixes the crashes for you though. Sorry, I have no experience when it comes to the tuner you have, so no recommendations i'm afraid. You could post a support.zip anyhow, so we can see more details about your setup and go from there.

http://www.DVBViewer.tv/forum/topic/2210-how-to-post-bugs-or-problems-correctly/

 

Edited December 1, 2013 by majstang

[Griga]

Aha, then I guess there's no chance for you to test RS 1.26 if you haven't downloaded it earlier. The DVBViewer company doesn't provide previous versions of anything, despite masses of users asks for it. It's a pity IMHO.

 

Things have changed. Recording Service 1.26 is still available in the Older Versions section.

[majstang]

 

Things have changed. Recording Service 1.26 is still available in the Older Versions section.

 

That is great news Thanks!

[mch]

Can you teach me how to properly downgrade to RS1.26 without lost of timers db ? Should I install also some older DVBV or can I use 5.2.9 ?

I will generate supportfile and post as soon as possible.

 

EDIT: Here is the log: http://rghost.net/private/50580761/5c14ddbd0a7e00f8be5530dd0b5d555f Hope it will help.

Edited December 1, 2013 by mch

[majstang]

You should be abled to use DVBV 5.2.9 with RS 1.26 without any problem. If all timers disappears after a rollback it's no big deal cuz it's easy to redo them. Often you have to repopulate the EPG after the rollback first and then timers. Don't worry about the recordings.db and recordings history db. These databases wont be affected at all.

[majstang]

Hi mch!

 

Had a look at your support.zip and there are a couple of things in your setup that needs to be adressed. First thing:

- You need to go over the Recording Service installation guide http://en.DVBViewer.tv/wiki/Recording_Service_Installation_Guide

and inactivate the tuners in DVBViewer-Options-Hardware tab and setup either Unicast- or RTSP-devices instead. Right now RS and DVBViewer fights about the control of your tuners. RS should own the control and stream content to the Unicast/RTSP devices in DVBViewer. In that way RS can act as the streamserver and DVBViewer as client. As is now the RTSP UDP tweak won't have any effect for ya, cuz you are not using the RTSP stream server at all and not using RS and DVBViewer as intended.

 

Second thing:

- Going over your RS logs it seems you're only using DVB-C? If so I suggest you to disable the DVB-T tuner in RS all together. Could be done via webinterface-configuration. Perhaps RS could be stable for you only using the DVB-C side of the tuner. It's a long shot but worth trying.

-Also your tuner driver seems to be really old (from 2009-01-13), and it could be it's not suited for use with Windows 7 x64, since it predates the actual OS itself.

[mch]

Ok, I will try setup it as you adviced

About the drivers I cant do more. Newer drivers simply dont exist Original Technisat drivers are even older. These drivers are from another Vendor which use exactly the same hw.

[mch]

Well, I have installed again DVBV 5.2.9+RS1.27 and setup by your advice. Also I have changed drivers to original Technisat. I have done it in the morning. After whole day of recording and waiting on recording (sleep and wake up was disabled!) in the evening the service again stopped working. I had try to restart DVBV RS but it stucked at state: "stopping". I had to make hard reset of comupter.

 

Everything on computer works fine except RS Could anyone from DVB Company investigate with me this issue ?

 

Here is new support log after re-install: http://rghost.net/private/50666427/ef3beaefb8d56e666a5d465deb12d94f

 

I think problem is here:

03.12.13 23:41:00.444 TRecording Release TechniSat UDST7000BDA DVB-C CTuner (2)
03.12.13 23:41:00.444 TRecording Destroy TechniSat UDST7000BDA DVB-C CTuner (2)
04.12.13 00:32:46.496 Start App ------------------------------------------------------------
04.12.13 00:32:46.496 DVBViewer Recording Service 1.27.0.0
04.12.13 00:32:46.496 TRecordingEngine Execute Start

 

Shouldnt be there any info about "Destroyed" the device? I think here it stopped work.

Edited December 4, 2013 by mch

[mch]

What a pity that noone from DVBViewer company want investigate this problem with me. Today I got stuck RS again. In the log is shown very similar as above:

 

07.12.13 10:26:00.987 TRecording Release TechniSat UDST7000BDA DVB-C CTuner (2)
07.12.13 10:26:00.987 TRecording Destroy TechniSat UDST7000BDA DVB-C CTuner (2)

...HERE SHOULD BE SOMETHING ABOUT DESTROYED THE TUNER, RIGHT?...BUT IT IS MISSING, WHY?
07.12.13 10:59:10.760 DDServicePreShutdown Start <-- restart here
07.12.13 11:09:44.529 Start App ------------------------------------------------------------
07.12.13 11:09:44.529 DVBViewer Recording Service 1.27.0.0
07.12.13 11:09:44.529 TRecordingEngine Execute Start

 

Small description again: Once a day or two my RS1.27 get stuck in state of "RECORDING", even if the program already finished and there is no other in Timer. If I try stop manually the recording service I see just "STOPPING" but it never stops and I have to restart the computer to get it working again.

 

PC specification: Win7x64 (old 2months maybe less incl. all updates!),brand computer HP 6200Pro SFF, Core i5-2500 3,3GHz, 12GB RAM, 80GB SSD(OS), 1TB(recordings), Nvidia Quadro K600 with recent nvidia certified drivers.

 

TUNER: USB dvbc/t tuner Technisat Cablestar Combo HD CI, latest drivers from Technisat (unfortunatelly quite old, but newer doesnt exist, link). I have also tried newer drivers from other Vendor which use the same HW (link)

 

SUPPORT TOOL LOG: newest log http://rghost.net/private/50772664/35081d8ea1bd8860e4b30a5b5efd46d9

 

Hope that finally someone from DVBViewer will reply because I have post all required information.

 

Thanks!

Edited December 7, 2013 by mch

[Griga]

I'm reading along here, but I didn't reply because I don't know how I can help. The hard part for me is understanding the internals of a mostly undocumented project with some 100.000 lines of code that I inherited unexpectedly. I managed to analyze parts of it and to fix some things (even more in the upcoming 1.28), but I'm still far away from understanding the whole.

 

The hard part for me is to understand how the non-blocking mode and larger buffer size could result in a crash when it's functionality haven't even kicked in yet?

 

Seems quite unlikely. However, it may be the result of something that happened before hibernation and that only takes effect in combination with it.

 

31.10.13 15:35:06.209 TRTSPWebserver Connect Could not connect 554

 

I can't reproduce it here, and I don't know what may cause this failure.

 

Maybe a short delay between initialization and connection, 100ms or so could do wonders to get rid of the fishy log at least.

 

Maybe. We would have to find out by trying different delays. Quite time consuming...

...HERE SHOULD BE SOMETHING ABOUT DESTROYED THE TUNER, RIGHT?...BUT IT IS MISSING, WHY?

 

You are right. The Recording Service stops working on device deallocation, even writing to the log doesn't continue. Looks like a driver malfunction causing a deadlock. There is nothing we can do about such an issue.

[mch]

Seems quite unlikely. However, it may be the result of something that happened before hibernation and that only takes effect in combination with it.

Do you think sleep mode of the computer or hibernation of the USB Tuner? Sleep mode of the computer I have disabled but Recording Service get stuck again. May I disable hibernation of the USB tuner in any way ?

 

You are right. The Recording Service stops working on device deallocation, even writing to the log doesn't continue. Looks like a driver malfunction causing a deadlock. There is nothing we can do about such an issue.

Maybe but I have tried two different drivers (Technisat+Azurewave) and both get stuck RS.Maybe you know other Vendor which use the same HW like my Technisat Cablestar Combo HD CI so I will be able to use their updated drivers??

 

Thanks!

Edited December 8, 2013 by mch

[majstang]

The interesting question is if the non-blocking mode or the increased buffer size.causes the crash in your case. You could try to lower the buffer size e.g. to 5000 or even 1000 packets, which proved to be sufficient in my setup. Maybe 10000 is far too much. We have to learn by experience...

 

I'm happy to report that my system is still stable after a month of testing with the value of 5000 packets.

I'll go for 10000 now to see if the crashes reappear.

 

Regards

majstang

[mch]

I am proud and happy that my configuration works also fine with DVBViewer v5.2.9 and RS1.28. Thanks for support guys!

I am not sure but I think it was really driver issue.