Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
>> If I pause live video then restart it starts in slo-mo i.e. judders, and >> then eventually freezes, but may then start again, still juddering …. >> and freezing … > > Well, then I have no idea why it wouldn't work with an NTFS partition, > while it does work with others. > > Klaus Hi Klaus, I have similar problems using a NFS share under some circumstances: The general problem is that the index file stops growing after a few seconds, while the 1.ts file growing normaly. 1. Using a local HDD with ReiserFS for recording, everything works well. 2. Using NFS V3 with the mount options tcp,hard,sync the index file stops growing. 3. Using NFS V3 with the mount options tcp,soft,async the index file keeps growing. I was happy figured that out, but there seems to be another problem. While having heavy network load this problem occurs again. An example: Cutting a movie on my NFS share, while recording a new movie to the same NFS share causes in the same problem, the index file stops growing. And... it does not start growing again, after the cutting has finished. This means that I have to stop/start the recording to get a correct index file again. Could it be possible, that the process which is writing the index dies in some kind? I've never had a problem like this in older VDR versions, and I often do cutting and recording at the same time. BTW: Is the a way to (re)create a new index file for TS like genvdr for VDR file did? -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
Hawes, Mark schrieb: > > > /If I pause live video then restart it starts in slo-mo i.e. judders, and/ > >>>/ then eventually freezes, but may then start again, still juddering …./ > >>>/ and freezing …/ > >>/ / > >>/ Well, then I have no idea why it wouldn't work with an NTFS partition,/ > >>/ while it does work with others./ > >>/ / > >>/ Klaus/ > > > >> Hi Klaus, > > > >> I have similar problems using a NFS share under some circumstances: > > > >> The general problem is that the index file stops growing after a few > >> seconds, while the 1.ts file growing normally. > > > >> 1. Using a local HDD with ReiserFS for recording, everything works well. > > > >> 2. Using NFS V3 with the mount options tcp,hard,sync the index file > >> stops growing. > > > >> 3. Using NFS V3 with the mount options tcp,soft,async the index file > >> keeps growing. I was happy figured that out, but there seems to be > >> another problem. > > > >> While having heavy network load this problem occurs again. > > > >> An example: > > > >> Cutting a movie on my NFS share, while recording a new movie to the same > >> NFS share causes in the same problem, the index file stops growing. > >> And... it does not start growing again, after the cutting has finished. > > > >> This means that I have to stop/start the recording to get a correct > >> index file again. > > > >> Could it be possible, that the process which is writing the index dies > >> in some kind? > > > >> I've never had a problem like this in older VDR versions, and I often do > >> cutting and recording at the same time. > > > >> BTW: Is the a way to (re)create a new index file for TS like genvdr for > >> VDR file did? > > > > > >> -Günter > > > > Hi, > > > > I have checked the recording directory and sure enough, the index file stops > growing after a short while (seconds). > > > > I have tried mounting the NTFS partition with the async option but to no > avail, i.e. problem is still there. > > > > BTW: How do I respond to an already open thread? All I seem to be able to do > is start a new one. > > > > Mark. > Hi, o.k. that is exactly the same problem I have. But here is a missunderstandig: I'm using a network share from my NAS mounted with NFS filesystem NOT NTFS. NTFS is a local filesystem on one of your local HDD's. Using NTFS you don't have a mount option like soft or async. Perhaps it depends on some kind of speed. NTFS is userspaced not kernel. I don't know. I'm using a normal email client like thunderbird, choose the mail I want to answer to, and everything is ok. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
>> I've never had a problem like this in older VDR versions, and I often do >> cutting and recording at the same time. > > Strange - the code for actually writing the index file hasn't changed > between PES and TS recording. But maybe you can take a closer look at > the changes to cIndexFile between version 1.7.2 and 1.7.3. The last VDR I used was 1.4.7 This is my first step with the new devel version 1.7.x I can't say when the problem occured first, but I try to figure it out, including older versions. Unfortunately I'm not experienced in C/C++, but I will give it a try. >> BTW: Is the a way to (re)create a new index file for TS like genvdr for >> VDR file did? > > I believe you mean 'genindex'. Yes, of course, I meant "genindex" - it was early in the morning. > Maybe I should make VDR automatically generate an index file when replaying > a TS recording without one... This sounds good, very good! And it would solve our problem here in some kind. I will come back here as far as I have news about. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
> Strange - the code for actually writing the index file hasn't changed > between PES and TS recording. But maybe you can take a closer look at > the changes to cIndexFile between version 1.7.2 and 1.7.3. Possibly you may want to have a look to my logfile, while the error occurs: snip Mar 22 12:25:06 vdr-142 vdr: [23234] record /video0/@Wintersport/2009-03-22.12.25.2-0.rec Mar 22 12:25:06 vdr-142 vdr: [23234] creating directory /video0/@Wintersport Mar 22 12:25:06 vdr-142 vdr: [23234] creating directory /video0/@Wintersport/2009-03-22.12.25.2-0.rec Mar 22 12:25:06 vdr-142 vdr: [23234] recording to '/video0/@Wintersport/2009-03-22.12.25.2-0.rec/1.ts' Mar 22 12:25:06 vdr-142 vdr: [2257] recording thread started (pid=23234, tid=2257) Mar 22 12:25:06 vdr-142 vdr: [2258] receiver on device 2 thread started (pid=23234, tid=2258) Mar 22 12:25:06 vdr-142 vdr: [2259] TS buffer on device 2 thread started (pid=23234, tid=2259) Mar 22 12:25:08 vdr-142 vdr: [23234] replay /video0/@Wintersport/2009-03-22.12.25.2-0.rec Mar 22 12:25:08 vdr-142 vdr: [23234] playing '/video0/@Wintersport/2009-03-22.12.25.2-0.rec/1.ts' Mar 22 12:25:09 vdr-142 vdr: [2260] dvbplayer thread started (pid=23234, tid=2260) Mar 22 12:25:09 vdr-142 vdr: [2261] non blocking file reader thread started (pid=23234, tid=2261) Mar 22 12:25:11 vdr-142 vdr: [23234] timer 1 (2 1225-1525 '@Wintersport') set to event Son 22.03.2009 13:05-15:00 (VPS: 22.03 10:15) 'Wintersport' Mar 22 12:25:14 vdr-142 vdr: [2258] buffer usage: 70% (tid=2257) Mar 22 12:25:14 vdr-142 vdr: [2258] buffer usage: 60% (tid=2257) Mar 22 12:25:14 vdr-142 vdr: [2258] buffer usage: 70% (tid=2257) Mar 22 12:25:15 vdr-142 vdr: [2258] buffer usage: 80% (tid=2257) Mar 22 12:25:16 vdr-142 vdr: [2258] buffer usage: 90% (tid=2257) Mar 22 12:25:17 vdr-142 vdr: [2258] buffer usage: 100% (tid=2257) Mar 22 12:25:17 vdr-142 vdr: [2258] ERROR: 1 ring buffer overflow (65 bytes dropped) Mar 22 12:25:23 vdr-142 vdr: [2258] ERROR: 19932 ring buffer overflows (3747216 bytes dropped) Mar 22 12:25:29 vdr-142 vdr: [2258] ERROR: 21852 ring buffer overflows (4108176 bytes dropped) Mar 22 12:25:35 vdr-142 vdr: [2258] ERROR: 19089 ring buffer overflows (3588732 bytes dropped) snap BTW: I just tried to replay this recording using vlc, and the TS file is also corrupted. Not only the index file stops, the ts file is also defect. Important: My NFS share has enough bandwidth to record three or more streams at the same time. No problem at all with older vdr's using the same share. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
> > Well, if there are buffer overflows and the TS data is corrupted, it's > no wonder the index file stops growing. > > Does this happen on all channels, or only on some (or even only on a > particular one)? Well, I've tried it on several channels ARD,ZDF,arte,Das Vierte,MünchenTV and so on. Channels with high (6-8MBits/s) and normal (3-4MBits/s) bandwidth. Every channel has the same problem. Using hard,sync,intr on NFS shares causes in a reduction of permanent write-throughput to roundabout 4,5 to 5,0 Mega Bytes/s. That should be enough to record two streams at the same time. Using soft,async,nointr on NFS shares causes in a higher permanent write-throughput to roundabout 9,5 to 10,0 Mega Bytes/s. With this setting, I can make two records at the same time, but a third one (record or playback or cutting) does not work well. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
> Well, if there are buffer overflows and the TS data is corrupted, it's > no wonder the index file stops growing. > > Does this happen on all channels, or only on some (or even only on a > particular one)? > Additional infos: I recompiled older versions beginning at 1.7.3 and made some tests. 1.7.3 acts exactly like 1.7.4 one record -> bufferoverflow The native networkthroughput is between 2,8-3,7 Mega Bytes /s for one stream. -> Much to high I think! 1.7.2 seems to be o.k. one record -> no problem -> throughput is between 0,8-1,2 MB/s two records -> no problem -> throughput is between 1,8-2,6 MB/s three records -> no problem -> throughput is between 2,8-4,0 MB/s four records -> PES pkt shortened -> throughput is between 3,8-5,4 MB/s All tested while using the "slower" NFS share. Why does one TS stream require a three times higher bandwidth in 1.7.3/1.7.4 than a PES stream in 1.7.2 do? I think we're getting closer to the problem :-) -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
> A TS recording is only marginally more data than the same length recording > in PES. I don't think that recording in TS should require so much more > bandwidth > than PES. That's clear to me. > There must be an other problem that's causing this, but since this doesn't > happen here on my system, I'm afraid you'll need to do the debugging ;-) No problem, I'll try "debugging" the problem with my tools :-), but I have no chance "debugging" in the code. :-( > Just to be sure: this *is* an unpatched version 1.7.4. we're talking about, > right? Yes, of course. It's installed from a fresh download, also 1.7.3 and 1.7.2 -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
...is there switch, or simple possibility to change recording format from TS to PES in 1.7.4 - just for a simple verification? BTW: In your environment, do you stream over net or local disk? Because streaming to a local (linux)disk makes no problem, and would be hard to produce it, or measure the diskload. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
> There must be an other problem that's causing this, but since this doesn't > happen here on my system, I'm afraid you'll need to do the debugging ;-) Which changes have been made between 1.7.2 and 1.7.3 in file writing mechanism? Not codechanges, because I dont understand them, but in words please. E.g. blocksize changed from xxx to yyy changed algo. changed cache or something else which can influence the performance. I found out, that in 172 the most time up to 20 stream data blocks are transmitted via NFS between one "NFS WRITE CALL / WRITE REPLAY" and "NFS COMMIT CALL / COMMIT REPLAY" combination and the next one. In 173/174 the number of stream data blocks decreases to an amount of 5 blocks maximal. Therefor the number of "NFS WRITE CALL / WRITE REPLAY" and "NFS COMMIT CALL / COMMIT REPLAY" combinations increases up to 4 to 5 times higher than in 172. This produces an enormous overhead, and this overhead could be reasonable for the two MegaByte/s networkoverload above the normal load with 1 MB/s per stream. Perhaps Klaus, you have an idea. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
> Here's a quick shot - totally untested (no time, sorry). > Please try it and let me know if it helps. Hi, I've tried it: files are created, but with zero filesize. Only info is correct. After a few seconds vdr is restarting with an "emergency exit!". -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
> Just another quick thing to test: please add > > } > Data += TS_SIZE; <== this line > Length -= TS_SIZE; > Processed += TS_SIZE; > } > return Processed; > } > > to the end of cFrameDetector::Analyze(). ...looks good at all! I've tested streaming of four channels via the "slow" NFS share without any problem until now. The overall netload was at a maximum of 4,5 MB/s for four streams. A single stream (ARD) needs roundabout 1,1 MB/s. ...Die ARD'ler müssen Geld und Bandbreite ohne Ende haben!!! -->15Min/850MB TS File Wonderful ! One question (OT): is it normal that replaying a PES record causes in a very high CPU load on 1.7.2 and higher? -> 80-90% on a P4/2400 Replaying TS produces "no" CPU load. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
> One question (OT): is it normal that replaying a PES record causes > in a very high CPU load on 1.7.2 and higher? -> 80-90% on a P4/2400 > > Replaying TS produces "no" CPU load. Forget it! This seems to be fixed too since your patch. Could that be possible? -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Instability with recordings on VDR-1.7.4 when recording to a NTFS partition
>>> Replaying TS produces "no" CPU load. >> Forget it! This seems to be fixed too since your patch. >> >> Could that be possible? > > I don't think so. The modified code is not involved > in replaying, only in recording. However, currently 174 works without high CPU load in my environment. I had no chance to reproduce it again yesterday. In 173 or 172 I can do. Is this a known problem? -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] from xineliboutput to ... perhaps softhdddevice?
Hi, I'm in the same situation, and most of my friends, using vdr the same way, too. The only software, I currently know which works similar, is VOMP client/server. It is also independant and could be run standalone on Linux and Windows. But it is IMHO only a "worst-case-replacement" for sxfe. I also don't want to have a complete vdr environment running, for only watching TV on my laptops or any other remote station. Thanks, Günter --- Am 14.04.2015 um 08:59 schrieb Matthias Wächter: Hi, I am currently using xineliboutput, and I'm using it with "--local=none" everywhere so I can attach and detach from anywhere in the LAN, even from the PC VDR is running on. It's working quite nicely this way. Upside: No local configuration on any PC, no concurrency issues with timers, channel updates etc.. just call "vdr-sxfe " and you're in the game. Downside: Multiple connected clients at the same time get the same programme, OSD, etc. [skippy/hanging video for adapting to the different client speeds, OSD sizing issues for different client resolutions] Is there an equivalent solution which I read to be a more recent/better supported alternative? AFAIK softhddevice is similar to xineliboutput but lacks remote features, behaves like xineliboutput with "--local=sxfe --noremote", but I could be wrong. This doesn't look like a viable alternative to my current network architecture. While streamdev and VNSI/XVDR solve some of the issues, most notably the multi-client dependency, they create new ones. No native OSD with VNSI/XVDR, VDR configuration synchronization hassle with streamdev. Is there any other thin-client streaming solution with native VDR OSD available? Any other suggestions? Thanks, - Matthias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr -- This message was scanned by ESVA and is believed to be clean. Click here to report this message as spam. http://esva.nk-hosting.de:10080/cgi-bin/learn-msg.cgi?id=D68AC160087.AB80D -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] from xineliboutput to ... perhaps softhdddevice?
Am 14.04.2015 um 09:56 schrieb Gerald Dachs: Am 2015-04-14 08:59, schrieb Matthias Wächter: While streamdev and VNSI/XVDR solve some of the issues, most notably the multi-client dependency, they create new ones. No native OSD with VNSI/XVDR, VDR configuration synchronization hassle with streamdev. use softhddevice + vdr + streamdev-client on the clients and connect to a streamdev-server on the main vdr. Gerald Well, that works so far, but it is not an effective substitute for the functionality of vdr-sxfe, at least not for what I use it mainly. All functions run on the remote machine, and only the screen is transferred to the local machine. -Günter -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR without PrimaryDVB but with xineliboutput ?
Hi, I use these config parameters for xineliboutput plugin --local=none --primary --remote=0.0.0.0:37890 in MLD 5.1. I have no local OSD because of using VDR as server, and I can use it on my Ubuntus as a remote display/client using vdr-sxfe... -Wanninger --- Am 21.12.2016 um 14:42 schrieb Harald Milz: On Tue, Dec 20, 2016 at 06:09:46PM +0100, Stephan Loescher wrote: Hi! I never tried it myself, but isn't vdr-dummydevice used for that? Hmmm, it seems xineliboutput doesn't like not being the primary: Dec 21 14:39:38 vdr vdr: [3419] [xine..put] Dropping client: xineliboutput is not the primary device ! I think I'll park the primary at a hotbird channel via SVDRP / cron for now. -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR without PrimaryDVB but with xineliboutput ?
That's right. I use two ways to solve that issue: 1. for example, tune VDR to a non existant iptv channel or another one, which does not use DVB ressources. 2. use of vdr-plugin-suspendoutput - works also fine for me --- Am 21.12.2016 um 16:36 schrieb Harald Milz: On Wed, Dec 21, 2016 at 03:14:29PM +0100, Niedermeier Günter wrote: I use these config parameters for xineliboutput plugin --local=none --primary --remote=0.0.0.0:37890 Yup, me too. In this case xineliboutput will be the primary display, and there will always be a channel running on it. Which is the root cause of my problem. If you omit --primary, xineliboutput will claim primary on its own if there is no other output device, which is the case when you have a receiver-only sat card. -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR without PrimaryDVB but with xineliboutput ?
Recent xineliboutput can trigger suspendoutput automatically when vdr- sxfe is disconnected (this could use some testing ...). See --auto- suspend option. Is it enough to replace the xineliboutput plugin with the latest git-version and start the plugin it with "-s" parameter, or must I do further things? Only updating the xineliboutput plugin does not trigger autosuspend yet. (At least in my environment) -Wanninger -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR without PrimaryDVB but with xineliboutput ?
Was there anything in the log when vdr-sxfe was started / stopped ? I can not say, because I forgot to/didn't look at any log. I'll give it a try with the new suspendoutput plugin. Thank you -Wanninger --- -- This message was scanned by ESVA and is believed to be clean. ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
