Re: [vdr] Problems playing ongoing recordings?
On Wednesday 26 March 2008 21:51:06 VDR User wrote: On Wed, Mar 26, 2008 at 12:03 PM, Artur Skawina [EMAIL PROTECTED] wrote: kind of hard to describe something you no longer remember... ;) I _think_ the issue was some kind of stuttering playback; it didn't happen always, but often enough that one day i decided to see if writing the stream in much larger chunks would help. It did; never seen it since. The only time I've heard about people having stuttering playback of recordings was when DMA wasn't turned on for their harddrive(s). Other then that, I don't know what to tell you. I playback recordings while they're still recording all the time and never experienced any problems. Maybe someone else can comment about this but otherwise it seems to be a dead topic. Artur is right. I am using the following VDR setup: 2 VDR machines in client(FF)/server(budget) mode (thank to streamdev) over wifi. The video folder is shared over the network in CIFS (aka Samba). Actually replaying VDR recording is not smooth all the time and the timeshifting on the client side is not working at all. Recording on the server and playing on the client at the same time result in smooth and freeze cycle with lip sync issue. Watching live programs is perfect. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-xine oh no not again...
Reinhard, I decided to try vdr 1.6.0 and vdr-xine 0.8.2 and have ran into the XINE VDR VERSION MISMATCH in INSTALL issue. I am running xine-lib 1.2 pulled from the xine site pkg-config --cflags libxine -I/usr/local/include I can't see what is wrong Cheers Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine oh no not again...
On Thu, Mar 27, 2008 at 11:02:45AM +0100, Tony Grant wrote: Reinhard, I decided to try vdr 1.6.0 and vdr-xine 0.8.2 and have ran into the XINE VDR VERSION MISMATCH in INSTALL issue. I am running xine-lib 1.2 pulled from the xine site pkg-config --cflags libxine -I/usr/local/include I can't see what is wrong I use this in order to be sure I only got ONE xine-lib installed : #!/bin/bash source /etc/make.conf p=vdr.patch MAKE='sudo nice -n 4 make -j3' OPTIONS=show update dry-run apply undry-run unapply compile log exit select opt in $OPTIONS; do if [ $opt = show ]; then vi $p elif [ $opt = update ]; then hg pull -u http://hg.debian.org/hg/xine-lib/xine-lib-1.2/ elif [ $opt = dry-run ]; then patch --dry-run -p1 $p elif [ $opt = apply ]; then patch -p1 $p elif [ $opt = undry-run ]; then patch --dry-run -p1 -R $p elif [ $opt = unapply ]; then patch -p1 -R $p elif [ $opt = compile ]; then sudo ./autogen.sh --disable-dxr3 --enable-opengl --enable-v4l \ --enable-glu --enable-dvb --prefix=/usr \ --with-alsa --with-external-ffmpeg --with-fontconfig \ --with-freetype --with-x --with-xv-path=/usr/X11R6/lib \ --x-includes=/usr/include $MAKE $MAKE install \ sudo rm -fr /usr/lib/xine $MAKE install $MAKE distclean elif [ $opt = log ]; then hg log|less elif [ $opt = exit ]; then exit else echo bad option fi done Just put this into your xine-lib-1.2 hg's source and adjust it if you don't want to install into /usr ;-) If you don't use gentoo, you could remove the source... and my p is only to have vdr fifo where I want them... (notice the rm -fr /usr/lib/xine which I only run if the install is successfull to be sure I can have a complete be unique xine install). Hope that could be of any help ;-) -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine oh no not again...
Le jeudi 27 mars 2008 à 12:15 +0100, Gregoire Favre a écrit : I use this in order to be sure I only got ONE xine-lib installed : Thanks Gregoire but I only have one xine-lib installed. This is a clean FC8 with xine-lib 1.2 installed from hg. Trying an update of xine-lib now (4 hours on a VIA Epia M1) Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine oh no not again...
On Thu, Mar 27, 2008 at 12:34:21PM +0100, Tony Grant wrote: Thanks Gregoire but I only have one xine-lib installed. This is a clean FC8 with xine-lib 1.2 installed from hg. Trying an update of xine-lib now (4 hours on a VIA Epia M1) I am quiete certain that you still have some files from the previous version... you don't have to recompil all, just delete all files in the location you installed it, and just do the make install part. -- Grégoire FAVRE http://gregoire.favre.googlepages.com http://www.gnupg.org http://picasaweb.google.com/Gregoire.Favre ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-xine oh no not again...
Le jeudi 27 mars 2008 à 12:54 +0100, Gregoire Favre a écrit : Trying an update of xine-lib now (4 hours on a VIA Epia M1) I am quiete certain that you still have some files from the previous version... you don't have to recompil all, just delete all files in the location you installed it, and just do the make install part. The update worked you were right there must have been some stuff from a previous hg update. Cheers Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr 1.6.0
OK I now have the following set up: - hush with VIA Epia M1 - Fedora Core 8 up to date except libX11* - xine-lib 1.2 from hg today 27/03/2008 - vdr 1.6.0 - vdr-xine 0.8.2 - femon 1.2.4 - vdradmin-am-3.6.1 *In order to use xine with xxmc hardware acceleration I have downgraded libX11 to the version from Fedora Core 7 - bug libX11 with xcb support xine still locks up if I change desktops to check my mail or if I try to use the right click configuration menu when running with vdr. Fine when running xine with other media files. I am now able to use pulseaudio in xine - recent updates of alsa and pulseaudio probably fixed the issues I was having. Sound can still be crappy when watching an avi file... Cheers Tony -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
That seems like a lot of bandwidth for wifi... ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
alexw wrote:
I _think_ the issue was some kind of stuttering playback; it didn't
happen always, but often enough that one day i decided to see if writing
the stream in much larger chunks would help. It did; never seen it since.
I am using the following VDR setup: 2 VDR machines in
client(FF)/server(budget) mode (thank to streamdev) over wifi. The video
folder is shared over the network in CIFS (aka Samba). Actually replaying VDR
I have a similar setup, just with 100M ethernet instead of wifi and NFS instead
of samba. wifi could be a problem, but if you're able to watch the same channel
live you should also be able to view a recording.
recording is not smooth all the time and the timeshifting on the client side
is not working at all.
Timeshifting on the client requires 3x the bandwith and a lot of data going in
both directions, so may not work all that well over wireless.
Recording on the server and playing on the client at
the same time result in smooth and freeze cycle with lip sync issue. Watching
live programs is perfect.
But this sounds very much like the problem i was seeing. In my case it was
dependent on the bitrate and number of simultaneous recordings IIRC.
If you'd like to try a patch, attached is what i've using since May 2007.
It could help, but might also not change anything at all; the main reason
i'm interested if it helps is because i have O_DIRECT support done on top
of this, and am not sure if i should keep the write coalescing for the case
where O_DIRECT isn't available.
It contains:
- various code cleanups (that i made after Klaus merged the fadvise-related
modifications, they make the patch a bit harder to read, but should be
otherwise harmless)
- tweaks to improve playback (smarter readahead)
- tweaks to improve cutting performance (didn't help much iirc)
- write coalescing - the stream is written in multi-megabyte chunks instead
of a dozen or so K at a time. This is the interesting part; it adds
another data copy, but seems to have made the stuttering playback disappear.
(this change will only make a difference when applied to the vdr that does
the recording, ie the server; the fadvise tweaks mentioned above could also
improve things when applied to the client)
Patch made against vdr-1.4.7, but applies to 1.6.0 too.
artur
diff --git a/cutter.c b/cutter.c
index 5170ae4..7e2e506 100644
--- a/cutter.c
+++ b/cutter.c
@@ -66,7 +66,8 @@ void cCuttingThread::Action(void)
toFile = toFileName-Open();
if (!fromFile || !toFile)
return;
- fromFile-SetReadAhead(MEGABYTE(20));
+ fromFile-CuttingSrc();
+ toFile-CuttingDst();
int Index = Mark-position;
Mark = fromMarks.Next(Mark);
int FileSize = 0;
@@ -91,7 +92,7 @@ void cCuttingThread::Action(void)
if (fromIndex-Get(Index++, FileNumber, FileOffset, PictureType,
Length)) {
if (FileNumber != CurrentFileNumber) {
fromFile = fromFileName-SetOffset(FileNumber, FileOffset);
- fromFile-SetReadAhead(MEGABYTE(20));
+ fromFile-CuttingSrc();
CurrentFileNumber = FileNumber;
}
if (fromFile) {
@@ -124,6 +125,7 @@ void cCuttingThread::Action(void)
error = toFile 1;
break;
}
+ toFile-CuttingDst();
FileSize = 0;
}
LastIFrame = 0;
@@ -164,6 +166,7 @@ void cCuttingThread::Action(void)
error = toFile 2;
break;
}
+toFile-CuttingDst();
FileSize = 0;
}
}
diff --git a/tools.c b/tools.c
index 255c806..a14f799 100644
--- a/tools.c
+++ b/tools.c
@@ -1055,7 +1055,8 @@ bool cSafeFile::Close(void)
#define USE_FADVISE
-#define WRITE_BUFFER KILOBYTE(800)
+//#define dfsyslog dsyslog // uncomment to turn on fadvise
related logging
+#define dfsyslog(a...) do {} while (0)
cUnbufferedFile::cUnbufferedFile(void)
{
@@ -1073,12 +1074,19 @@ int cUnbufferedFile::Open(const char *FileName, int
Flags, mode_t Mode)
fd = open(FileName, Flags, Mode);
curpos = 0;
#ifdef USE_FADVISE
- begin = lastpos = ahead = 0;
- cachedstart = 0;
- cachedend = 0;
- readahead = KILOBYTE(128);
+ lastpos = 0;
+ lastjump = 0;
+ cachedstart = cachedend = 0;
+ // 4M readahead seems to work for playback while cutting,
+ // but isn't quite enough for FF while cutting...
+ readahead = MEGABYTE(12);
+ writebuffer = KILOBYTE(2000);
written = 0;
totwritten = 0;
+ cutting = 0;
+
+ wbuf = NULL;
+
if (fd = 0)
posix_fadvise(fd, 0, 0, POSIX_FADV_RANDOM); // we could use
POSIX_FADV_SEQUENTIAL, but we do our own readahead, disabling the kernel one.
#endif
@@ -1087,6 +1095,11 @@ int cUnbufferedFile::Open(const char *FileName, int
Flags, mode_t Mode)
int
Re: [vdr] Problems playing ongoing recordings?
On Thu, Mar 27, 2008 at 9:19 AM, Artur Skawina [EMAIL PROTECTED] wrote: I have a similar setup, just with 100M ethernet instead of wifi and NFS instead of samba. wifi could be a problem, but if you're able to watch the same channel live you should also be able to view a recording. Takes a lot more bandwidth to record playback then just to record so the fact that live tv is fine doesn't amount to much I don't think. Btw, my setup was similar as well. Nexus-s card with 100 ethernet (wired). ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Problems playing ongoing recordings?
VDR User wrote: On Thu, Mar 27, 2008 at 9:19 AM, Artur Skawina [EMAIL PROTECTED] wrote: I have a similar setup, just with 100M ethernet instead of wifi and NFS instead of samba. wifi could be a problem, but if you're able to watch the same channel live you should also be able to view a recording. Takes a lot more bandwidth to record playback then just to record so the fact that live tv is fine doesn't amount to much I don't think. I was referring to playing a finished recording and playing a file that is currently being extended by the server vdr -- alexw said that doesn't work well for him. It should, unless the disk and/or fs can't handle the two data streams concurrently, while keeping the latency low enough. I'm assuming the vdr server in powerful enough to handle the load, yes. artur ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 and syncearly
Hi, Boguslaw Juza schrieb: Is the syncearly patch needed for new vdr? I'd say it's suggested. At least it is part of my H.264 patches. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 and syncearly
On Thu, 27 Mar 2008, Reinhard Nissl wrote: Is the syncearly patch needed for new vdr? I'd say it's suggested. At least it is part of my H.264 patches. Did you create H.264 patches for VDR-1.6.0? Boguslaw Juza ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.6.0 and syncearly
Hi, Boguslaw Juza schrieb: Is the syncearly patch needed for new vdr? I'd say it's suggested. At least it is part of my H.264 patches. Did you create H.264 patches for VDR-1.6.0? No. The patches for 1.5.8 should still work. What I recall, 1.6.0 did only complete translation. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:[EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] beep-0.1.0
Hello, her is a new release of my little plugin beep. This Plugin notify with a beep over the internal mainboard speaker, to selected VDR events. Project's homepage: http://www.deltab.de/content/view/75/76/ http://www.deltab.de/content/view/25/62/ Changes: - Updated i18n handling, required vdr-1.6 Enjoy, Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] extb-0.3.0
Hello, her is a new release of plugin extb. (This Plugin control a extension board.) Project's homepage: http://www.deltab.de/content/view/74/76/ http://www.deltab.de/content/view/24/63 Changes: - Updated i18n handling, required vdr-1.6 Enjoy, Andreas ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] Direct I/O support v1
This change makes vdr write the video stream directly to disk, bypassing
OS caches. O_DIRECT is used if it is supported, falling back to normal
I/O and fadvise() if not. Only recording is affected, playback remains
unchanged.
I did this to see if using direct i/o made sense for vdr, wasn't convinced
before. Avoiding all the fadvise hacks and especially the fdatasyncs on
close seems to be worth it though.
Only lightly tested, but seems to work, i tried a few recordings on both
ext3 and NFS and didn't notice any missing data yet ;) Upgraded all vdrs
and will keep testing for some time, but in case anyone else would like
to try (or even better improve) it, patch is below.
This patch is based on top of the one I posted in the Problems playing
ongoing recordings? thread, so you'll need to apply that one before
applying this one. Should work on both 1.4 and 1.6.
artur
diff --git a/tools.c b/tools.c
index a14f799..b7281b0 100644
--- a/tools.c
+++ b/tools.c
@@ -1054,6 +1054,11 @@ bool cSafeFile::Close(void)
// --- cUnbufferedFile ---
#define USE_FADVISE
+#define USE_DIRECTIO
+
+// O_DIRECT can have various alignment restrictions, usually at most
+// the block size of the filesystem. 4096 bytes should be enough.
+#define ALIGN_DIO 4096
//#define dfsyslog dsyslog // uncomment to turn on fadvise
related logging
#define dfsyslog(a...) do {} while (0)
@@ -1071,7 +1076,17 @@ cUnbufferedFile::~cUnbufferedFile()
int cUnbufferedFile::Open(const char *FileName, int Flags, mode_t Mode)
{
Close();
- fd = open(FileName, Flags, Mode);
+#ifdef USE_DIRECTIO
+ if (Flags(O_WRONLY|O_RDWR)) {
+ fd = open(FileName, Flags|O_DIRECT, Mode);
+ directio = 1;
+ }
+#endif
+ if (fd==-1) {
+ directio = 0;
+ fd = open(FileName, Flags, Mode);
+ }
+ dsyslog(Using %s IO to access %s, directio?DIRECT:normal, FileName);
curpos = 0;
#ifdef USE_FADVISE
lastpos = 0;
@@ -1101,7 +1116,7 @@ int cUnbufferedFile::Close(void)
free(wbuf);
}
#ifdef USE_FADVISE
- if (fd = 0) {
+ if (fd = 0 || !directio) {
if (totwritten)// if we wrote anything make sure the data has hit the
disk before
fdatasync(fd); // calling fadvise, as this is our last chance to
un-cache it.
posix_fadvise(fd, 0, 0, POSIX_FADV_DONTNEED);
@@ -1243,7 +1258,36 @@ ssize_t cUnbufferedFile::Read(void *Data, size_t Size)
ssize_t cUnbufferedFile::WriteBuf(const void *Data, size_t Size)
{
if (fd =0) {
- ssize_t bytesWritten = safe_write(fd, Data, Size);
+ ssize_t bytesWritten;
+
+#ifdef USE_DIRECTIO
+ if (directio) {
+// write properly sized buffers directly.
+if ((Size (ALIGN_DIO-1)) == 0) {
+ bytesWritten = safe_write(fd, Data, Size);
+ curpos += bytesWritten;
+ return bytesWritten;
+}
+// in the unlikely case of a short write (inevitable when closing)
+// pad the data with zeros, write it, then truncate the file.
+int padding = ALIGN_DIO - (Size (ALIGN_DIO-1));
+memset((char *)Data+Size, 0, padding);
+bytesWritten = safe_write(fd, Data, Size+padding);
+
+padding = bytesWritten - Size;
+if (padding0)
+ padding = 0;
+bytesWritten -= padding;
+curpos += bytesWritten;
+
+lseek(fd, -padding, SEEK_CUR);
+ftruncate(fd, curpos);
+// note: past this point the file offset is likely unaligned
+// so further directio shouldn't happen.
+return min(bytesWritten, (ssize_t)Size);
+ }
+#endif
+ bytesWritten = safe_write(fd, Data, Size);
//dsyslog(WRIT: fd:%3d %9zd .. %9zd SIZE: %6zd, fd, curpos,
curpos+Size, Size);
#ifdef USE_FADVISE
if (bytesWritten 0) {
@@ -1296,18 +1340,23 @@ ssize_t cUnbufferedFile::Write(const void *Data, size_t
Size)
{
if (!wbuf) {
wbuf_chunk = cutting?MEGABYTE(8):MEGABYTE(4);
- wbuf = MALLOC(uchar,wbuf_chunk);
- if (!wbuf)
+ if (posix_memalign(wbuf, ALIGN_DIO, wbuf_chunk)) {
+directio = 0;
return WriteBuf(Data, Size);
+ }
wbuf_len = 0;
}
if (Size = wbuf_chunk-wbuf_len) {
memcpy(wbuf+wbuf_len, Data, Size);
wbuf_len += Size;
} else {
- WriteBuf(wbuf, wbuf_len);
- memcpy(wbuf, Data, Size);
- wbuf_len = Size;
+ unsigned l = wbuf_chunk-wbuf_len;
+ if (l)
+memcpy(wbuf+wbuf_len, Data, l);
+ WriteBuf(wbuf, wbuf_chunk);
+
+ memcpy(wbuf, (char *)Data+l, Size-l);
+ wbuf_len = Size-l;
}
return Size;
}
diff --git a/tools.h b/tools.h
index ce7283c..c2ff493 100644
--- a/tools.h
+++ b/tools.h
@@ -255,6 +255,7 @@ private:
size_t written;
size_t totwritten;
int cutting;
+ int directio;
size_t writebuffer;
int FadviseDrop(off_t Offset, off_t Len);
int FadviseRead(off_t Offset, off_t Len);
___
vdr mailing list
vdr@linuxtv.org
