On 09 Aug 2005 "Christoph Hermanns" <Christoph.Hermanns(a)web.de> wrote:
> Am Sun, 7 Aug 2005 20:08:17 +0000 (UTC) schrieb Stefan Huelswitt
> <s.huelswitt(a)gmx.de>:
>
>> On 07 Aug 2005 "Christoph Hermanns" <Christoph.Hermanns(a)web.de> wrote:
>>
>>> How can i speed up the starting of the dvb driver and vdr ?
>>
>> If you're using a FF dvb card, loading the firmware takes some
>> time.
>>
>> You can speed up this (…
[View More]or actually hide some time) if you don't
>> let runvdr load the driver but rather create an own startup
>> script to load the driver and run this one very first after boot
>> i.e. S01. You have to background (&) the make insmod call.
>>
>
>
> Is this correct:
>
> 1. Comment out the start of dvb driver in runvdr:
>
> # Load driver if it hasn't been loaded already:
> #if [ $LSMOD -eq 0 ] ; then
> # (cd $DVBDIR; make insmod)
> # fi
>
> 2. Create new dvb-start.sh script (is the & at the right place ?):
> # Load driver if it hasn't been loaded already:
> if [ $LSMOD -eq 0 ] ; then
> (cd $DVBDIR; &make insmod)
> fi
No, won't work that way.
One problems is, that if you background the make insmod, the boot
process continues while the firmware is loaded. If the rest of
the boot script is fast, you may end with the situation that vdr
starts up before the make insmod is finished.
So I do to load the driver (may be a own script. I do it in boot
directly) (you have to adjust the dvb driver path):
( touch /tmp/dvb-insmod; \
cd /usr/local/source/dvb; make insmod;
rm /tmp/dvb-insmod ) &
In runvdr I check for the existance of the trigger file:
while [ -a /tmp/dvb-insmod ]; do
sleep1
done
This way the vdr startup is delayd until the insmod is finished.
(may be there are mor sofisticated method to do this, but it
works).
> Question: If the dvb-driver hangs, will the restart be unaffected from
> this change ?
> (I think so, but i'll ask to be sure ;-)
No, the restart won't be affected.
Regards.
--
Stefan Huelswitt
s.huelswitt(a)gmx.de | http://www.muempf.de/
[View Less]
VDR developer version 1.3.29 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.29.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.28-29.diff
The changes since version 1.3.28:
- Fixed a race condition in cTransfer (thanks to Klaus ??? for reporting this one).
In doing so, the 'active' variables used by the actual derived cThread classes
have been replaced by the cThread::Running() function.
Plugin …
[View More]authors may want to check their derived cThread classes and replace any 'active'
variables the same way as, for instance, done in transfer.c.
- Fixed handling EPG data for time shifted events (thanks to Marco Schlüßler).
- Increased the default value for 'Min. user inactivity' to 300 minutes (suggested
by Helmut Auer).
- Now storing the channel id in the info.vdr file even if there is no EPG info
available (thanks to Andreas Brachold for reporting that there are empty info.vdr
files created in that case).
- Added some 'mkdir -p' to the Makefile's 'install' target (thanks to Wayne Keer).
- Changed the title of the recording info menu (thanks to Rolf Ahrenberg).
- Fixed handling the frame number display if '7' is pressed before the first editing
mark, or '9' after the last one (thanks to Thomas Günther).
- Now discarding any previous numerical input to switch channels if Up, Down, Channel+,
Channel-, Left or Right is pressed (thanks to Wolfgang Rohdewald for reporting a
problem with this).
- Pressing Ok while entering a channel number now immediately switches to that
channel, without waiting for further input.
- Avoiding unnecessary OSD draw operations caused by the audio track description
display in the ST:TNG skin's channel display (thanks to Oliver Endriss for reporting
this).
- Removed the VIDEO_STILLPICTURE_WORKS_WITH_VDR_FRAMES stuff from
cDvbDevice::StillPicture(), since apparently the VIDEO_STILLPICTURE call works.
Have fun!
Klaus
_______________________________________________
vdr mailing list
vdr(a)linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[View Less]
zap.tartarus.org is currently down. It was moved last week and hasn't been
right since. I can't access it and have no idea when it'll be back up.
Until it's back up, you can find my current .diff.gz and .dsc files here:
<URL:http://www.youmustbejoking.demon.co.uk/tmp/>
You'll need to get source from upstream and build whichever packages you want
yourself. I don't have space for all of the source, never mind the .debs...
For vdr, the suggested build/install order is this:
Build …
[View More]xine-lib
Install libxine1, libxine-dev
Build vdr
Install vdr-dev
Build $PLUGINS
Install $PLUGINS, vdr
For building, I recommend "debuild binary" (you'll need devscripts).
--
| Darren Salt | d youmustbejoking,demon,co,uk | nr. Ashington,
| Debian, | s zap,tartarus,org | Northumberland
| RISC OS | @ | Toon Army
| <URL:http://www.youmustbejoking.demon.co.uk/> (PGP 2.6, GPG keys)
Brain failure (cortex dumped)
[View Less]
On 16 Aug 2005 "Christoph Hermanns" <Christoph.Hermanns(a)web.de> wrote:
> Am Tue, 9 Aug 2005 19:17:04 +0000 (UTC) schrieb Stefan Huelswitt
> <s.huelswitt(a)gmx.de>:
>
>> In runvdr I check for the existance of the trigger file:
>>
>> while [ -a /tmp/dvb-insmod ]; do
>> sleep1
>> done
>>
>> This way the vdr startup is delayd until the insmod is finished.
>> (may be there are mor sofisticated method to do this, but it
…
[View More]>> works).
>
> I've tried this and it works with the trigger file, but it's about
> 10 seconds slower than without checking the existing of the trigger file.
> Strange...don't know....
Probably because without the trigger file, vdr start up before
the driver finished loading. If it works it's ok, but I saw the
risk that the driver is not "ready enough" and vdr startup fails.
Regards.
--
Stefan Huelswitt
s.huelswitt(a)gmx.de | http://www.muempf.de/
[View Less]
Hi,
Dominique Simon wrote:
>> VDR developer version 1.3.28 is now available at
>
> As in 1.3.26 when the cVideoRepacker was introduced, it's making the
> same problem again. e.g. when i watch a recording and a timer starts,
> VDR crashes like this:
[snip]
> Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 4
> bytes to sync on next picture
> Aug 9 20:12:09 linvdr user.debug vdr[1808]: buffer usage: 70%
(tid=66573)
> Aug 9 20:12:10 …
[View More]linvdr user.debug vdr[1808]: buffer usage: 80%
(tid=66573)
> Aug 9 20:12:11 linvdr user.debug vdr[1808]: buffer usage: 90%
(tid=66573)
> Aug 9 20:12:12 linvdr user.debug vdr[1808]: buffer usage: 100%
> (tid=66573)
> Aug 9 20:12:12 linvdr user.err vdr[1808]: ERROR: 1 ring buffer
> overflow (65 bytes dropped)
> Aug 9 20:12:18 linvdr user.err vdr[1808]: ERROR: 14271 ring buffer
> overflows (2682948 bytes dropped)
> Aug 9 20:12:24 linvdr user.err vdr[1808]: ERROR: 18048 ring buffer
> overflows (3393024 bytes dropped)
> Aug 9 20:12:30 linvdr user.err vdr[1808]: ERROR: 16976 ring buffer
> overflows (3191488 bytes dropped)
> Aug 9 20:12:32 linvdr user.err vdr[1806]: ERROR: video data stream
broken
> Aug 9 20:12:32 linvdr user.err vdr[1806]: initiating emergency exit
> How can i turn that cVideoRepacker off again? VDR 1.3.26 worked like a
> charm...
It's the same switch by which you could enable it in VDR-1.3.27
(TEST_cVideoRepacker, remux.c:1279). But please help me fix this issue
instead of turning it off.
Strange is the timestamp 20:12:02: at this time, cVideoRepacker seems to
be in sync, but for any reason, it seems to process no more data as at
20:12:32 the recording is aborted with "ERROR: video data stream broken"
which indidates, that the recorder didn't see any data for 30 seconds.
Simon Baxter sent me a similar report, but with debug code inserted
which showed that cVideoRepacker wasn't completely stuck.
Is it easy for you to trigger this issue? I've tried two simultanuous
timers plus watching a recording but couldn't trigger the issue.
Please add the following 4 lines, which are marked with "<========" to
the appropriate source locations (cRepacker::Put(),
cVideoRepacker::Repack()) in remux.c and send me the output when the
problem happens again.
static int Put(.....)
{
esyslog(">>>>> cRepacker::Put(%d)", Count); // <============
int n = ResultBuffer->Put(Data, Count);
if (n != Count)
esyslog(.....);
esyslog("<<<<< cRepacker::Put"); // <============
return n;
}
.
.
.
void cVideoRepacker::Repack(.....)
{
esyslog(">>>>> cVideoRepacker::Repack(%d)", Count); // <============
// synchronisation is detected some bytes after frame start.
const int SkippedBytesLimit = 4;
// reset local scanner
localStart = -1;
.
.
.
// report that syncing dropped some bytes
if (skippedBytes > SkippedBytesLimit) {
esyslog(.....);
skippedBytes = SkippedBytesLimit;
}
esyslog("<<<<< cVideoRepacker::Repack()"); // <============
}
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@gmx.de
[View Less]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
HGM.bg (GMX) wrote:
> Malte Schröder wrote:
>
>
>>when I set the epg-scan timeout to something greater than 0, VDR
>>crashes reproducible. Attached is a piece of the log when it
>>happened. I was watching a recording.
>
>
> Just a question, what's the setting for the watchdog-timer and how big
> is your video-disk and how many recordings you have ? Big disks with
> many recording are eating a lot of …
[View More]vdr's power....
Timer is 60 Seconds, I currently have 47 recordings using 57GiB. The
disk is a 120GB from Samsung. So Nothing out of the ordenary I think.
>
>
>>Any clue what could cause this?
>
>
> Perhaps, just give some more infos please
>
>
>>Greets
>
>
> /hgm.bg
>
>
> _______________________________________________
> vdr mailing list
> vdr(a)linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
- --
- ---------------------------------------
Malte Schröder
MalteSch(a)gmx.de
ICQ# 68121508
- ---------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDAWtq4q3E2oMjYtURAkYqAKCTlsL21Y9P1BNwaeXMeI9shswPYgCgsNhB
Vk4MQpvmOqji/FArgJPlcj0=
=5Mn3
-----END PGP SIGNATURE-----
[View Less]
Hello,
I get the feeling that 1.4 might be getting close - so I though I should
speak up now.
I have a request: find a way to fix transfer mode while using a
motorised dish.
I have a dxr3 based system and a motorized dish. The problem is vdr
only waits a few seconds (TUNER_LOCK_TIMEOUT set in device.c) before it
reports "ERROR: device %d has no lock" and gives up.
This makes it fairly painful. I have to change channel, wait for the
dish to move and then go "menu->channels->OK" to re-…
[View More]tune the current
channel.
My "Fix" is not to return false after the timeout. This causes vdr to
try to set up the filters anyway, and things work fine. When the dish
moves the channels just starts to work fine. (If I am not wrong, vdr
used to have no timeout here but some cards did not like you to set
filters when there was no lock... ?) Setting the timeout to a large
value is not an option as vdr is unresponsive during this period, making
channel surfing 'stick' at various places where channels are
un-available. I cannot think of a fix that preserves the "don't set
filters without a lock" behaviour without using another thread.
The other problem with vdr and motorised dishes is due to the timeout
for recordings. If vdr receives no data for MAXBROKENTIMEOUT defined in
recording.c it does an emergency restart. Now on the plus side, by the
time vdr restarts my dish has (so far) always moved to the correct
position! However, I must say it is hard to explain to my wife why the
recording we just happened to be watching at the time stopped midway
through...
Maybe some of this could be fixed by to rotor plugin, however the rotor
plugin should not be needed in this setup (I just define things in
diseqc.conf). The better fix IMHO would be in vdr itself. I think a
parameter that says "maximum timeout when changing source" might help
the recording problem. Not so sure for the transfer mode problem.
[View Less]
Hello,
Attached is a patch so VDR does not error during the installation if the man
directories do not exist. Also, this patch installs the plugins as well as the
vdr binary when "make install" is used.
Best Regards,
C.Y.M.