Re: [vdr] ERROR: video data stream broken on second dvb card , but szap works (new findings!)
Hi,
Dieter Bloms wrote:
> my primary dvb card works fine on both of my Twin-LNB connectors.
> I can switch the second card via szap and get a video stream via
> "cat /dev/dvb/adapter1/dvr0 > /tmp/bla" on H and V channels.
> VDR doesn't get data any data from H channels, but gets data from V
> channels.
> I will try to strace vdr and szap to get any difference, maybe they do
> it in a different way.
I've had a further look into szap's source how it detects the status
FE_LOCKED. Attached is an updated tuner patch which now also reports
details for FE_READ_STATUS.
One difference between VDR and szap regarding FE_READ_STATUS is, that
VDR only honors the read status when ioctl() returns 0 while szap prints
just an error when ioctl() returns -1.
Furthermore, VDR's handling of errno == EINTR seems to be wrong due to
the do {} while (0); loop.
BTW: I still assume, that your logfile reports a tuning timeout. If this
is no longer the case, then you may want to experiment with
WAIT_FOR_TUNER_LOCK in device.c.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
--- ../vdr-1.4.5-orig/dvbdevice.c 2006-08-14 11:38:32.0 +0200
+++ dvbdevice.c 2007-02-18 12:23:47.0 +0100
@@ -147,6 +147,15 @@ bool cDvbTuner::Locked(int TimeoutMs)
return tunerStatus >= tsLocked;
}
+#include
+static double now() { int e = errno; timeval t; gettimeofday(&t, 0); errno = e; return t.tv_sec + t.tv_usec / 1e6; }
+static int check(int c, int r, char *a, double t) { int e = errno; fprintf(stderr, "t: %.3lf, c: %d, r: %d, a: %s\n", t, c, r, a); errno = e; return r; }
+static int check5(int status, int c, int r, char *a, double t) { int e = errno; fprintf(stderr, "t: %.3lf, c: %d, r: %d, a: %s => Status: %02x\n", t, c, r, a, status); errno = e; return r; }
+#define CHECK5(s) ::check5(Status, cardIndex, s, #s, ::now())
+#define CHECK4(s) ::check(cardIndex, 0, s, ::now())
+#define CHECK3(s) ::check(cardIndex, s, #s, ::now())
+#define CHECK2(s) CHECK(::check(cardIndex, s, #s, ::now()))
+
bool cDvbTuner::GetFrontendStatus(fe_status_t &Status, int TimeoutMs)
{
if (TimeoutMs) {
@@ -157,15 +166,16 @@ bool cDvbTuner::GetFrontendStatus(fe_sta
; // just to clear the event queue - we'll read the actual status below
}
}
- do {
- int stat = ioctl(fd_frontend, FE_READ_STATUS, &Status);
- if (stat == 0)
-return true;
- if (stat < 0) {
-if (errno == EINTR)
- continue;
+ while (1) {
+int stat = CHECK5(ioctl(fd_frontend, FE_READ_STATUS, &Status));
+if (stat == 0)
+ return true;
+if (stat < 0) {
+ if (errno == EINTR)
+ continue;
+ }
+break;
}
- } while (0);
return false;
}
@@ -195,12 +205,12 @@ bool cDvbTuner::SetFrontend(void)
for (char *CurrentAction = NULL; (da = diseqc->Execute(&CurrentAction)) != cDiseqc::daNone; ) {
switch (da) {
case cDiseqc::daNone: break;
-case cDiseqc::daToneOff: CHECK(ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF)); break;
-case cDiseqc::daToneOn:CHECK(ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_ON)); break;
-case cDiseqc::daVoltage13: CHECK(ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13)); break;
-case cDiseqc::daVoltage18: CHECK(ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_18)); break;
-case cDiseqc::daMiniA: CHECK(ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_A)); break;
-case cDiseqc::daMiniB: CHECK(ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B)); break;
+case cDiseqc::daToneOff: CHECK2(ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_OFF)); break;
+case cDiseqc::daToneOn:CHECK2(ioctl(fd_frontend, FE_SET_TONE, SEC_TONE_ON)); break;
+case cDiseqc::daVoltage13: CHECK2(ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_13)); break;
+case cDiseqc::daVoltage18: CHECK2(ioctl(fd_frontend, FE_SET_VOLTAGE, SEC_VOLTAGE_18)); break;
+case cDiseqc::daMiniA: CHECK2(ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_A)); break;
+case cDiseqc::daMiniB: CHECK2(ioctl(fd_frontend, FE_DISEQC_SEND_BURST, SEC_MINI_B)); break;
case cDiseqc::daCodes: {
int n = 0;
uchar *codes = diseqc->Codes(n);
@@ -208,7 +218,7 @@ bool cDvbTuner::SetFrontend(void)
struct dvb_diseqc_master_cmd cmd;
memcpy(cmd.msg, codes, min(n, int(sizeof(cmd.msg;
cmd.msg_len = n;
-CHECK(ioctl(fd_frontend, FE_DISEQC_SEND_MASTER_CMD, &cmd));
+CHECK2(ioctl(fd
[vdr] Strange delay in recordings with vdr-xine
I recently (more on that below) started experiencing a strange problem with vdr 1.4.5-1 and vdr-xine 0.7.6+network patches: while replaying a recording (either against a local copy of vdr or over the network) the only command that acts immediately is pause, every other one (skip one minute, ff, rew, stop) takes effect after a delay of 5-6 seconds, so, e.g., if I go back to the recordings menu, playback will still go on for 5-6 seconds. This wouldn't be such a big problem if it wasn't for teletext subtitles, since they appear 5-6 seconds earlier (i.e. the osd is instantaneous while the replay is lagging 5 seconds). The strange thing is that this didn't happen before, the only change is the laptop (but with the same hard disk: 3 months ago my laptop broke, I was given a similar one in which installed the old hard disk. Meanwhile I upgraded the kernel to 2.6.17, using the replacement laptop, with no problems, until now, when I got my repaired laptop back and this problem appeared). The main difference between the 2 laptops is the video card: the current one has a mobility/radeon 9000 and 1400x1050 resolution, while the replacement one had an intel chipset, 1024x768. I upgraded vdr while using the replacement laptop, but I'm pretty sure I maintained the same version of vdr-xine all the time. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Strange delay in recordings with vdr-xine
I have the same problem with xineliboutput (xvdr:tcp://). I don't remember when it all started but I don't think is related to xine. This is just a guess, but it may be related to the problem with recordings. When xine.. plugins worked OK I could record up to 5 channels in the same time. Now I can olny record 2 and the OSD has long delays after I start them (this is without using xineliboutput, only local display from FF card) Regards, Ilariu On 2/18/07, Luca Olivetti <[EMAIL PROTECTED]> wrote: I recently (more on that below) started experiencing a strange problem with vdr 1.4.5-1 and vdr-xine 0.7.6+network patches: while replaying a recording (either against a local copy of vdr or over the network) the only command that acts immediately is pause, every other one (skip one minute, ff, rew, stop) takes effect after a delay of 5-6 seconds, so, e.g., if I go back to the recordings menu, playback will still go on for 5-6 seconds. This wouldn't be such a big problem if it wasn't for teletext subtitles, since they appear 5-6 seconds earlier (i.e. the osd is instantaneous while the replay is lagging 5 seconds). The strange thing is that this didn't happen before, the only change is the laptop (but with the same hard disk: 3 months ago my laptop broke, I was given a similar one in which installed the old hard disk. Meanwhile I upgraded the kernel to 2.6.17, using the replacement laptop, with no problems, until now, when I got my repaired laptop back and this problem appeared). The main difference between the 2 laptops is the video card: the current one has a mobility/radeon 9000 and 1400x1050 resolution, while the replacement one had an intel chipset, 1024x768. I upgraded vdr while using the replacement laptop, but I'm pretty sure I maintained the same version of vdr-xine all the time. Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: video data stream broken on second dvb card , but szap works (new findings!)
Hi,
I will ike accentuate the do {}while(0) behavior.
I've seen this in few projects including VDR and at least one plugin
(xineliboutput)
In a code like:
do {
if (condition1)
continue;
} while(condition2);
continue does not translate to a jump to "do", but to a jump to "while"
where the condition2 is evaluated.
do {
if (condition1)
continue;
} while(0);
if equivalent with:
do {
if (condition1)
break;
} while (0);
Regards,
Ilariu
On 2/18/07, Reinhard Nissl <[EMAIL PROTECTED]> wrote:
Hi,
Dieter Bloms wrote:
> my primary dvb card works fine on both of my Twin-LNB connectors.
> I can switch the second card via szap and get a video stream via
> "cat /dev/dvb/adapter1/dvr0 > /tmp/bla" on H and V channels.
> VDR doesn't get data any data from H channels, but gets data from V
> channels.
> I will try to strace vdr and szap to get any difference, maybe they do
> it in a different way.
I've had a further look into szap's source how it detects the status
FE_LOCKED. Attached is an updated tuner patch which now also reports
details for FE_READ_STATUS.
One difference between VDR and szap regarding FE_READ_STATUS is, that
VDR only honors the read status when ioctl() returns 0 while szap prints
just an error when ioctl() returns -1.
Furthermore, VDR's handling of errno == EINTR seems to be wrong due to
the do {} while (0); loop.
BTW: I still assume, that your logfile reports a tuning timeout. If this
is no longer the case, then you may want to experiment with
WAIT_FOR_TUNER_LOCK in device.c.
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 mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Capabilities
Hello, I've problems with my statusleds plugin. If vdr is not running as root all capabilities are dropped - except the one for setting the system time. My plugin wants to set the keyboard leds with the ioctl KDSETLED on /dev/console. Unfortunately this ioctl requires one more capability. Is there any way to get this capability? Should we extend the plugin interface with a possibility for the plugins to specify needed caps? Greetings, Bernd ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] RS-232 relay plugin adapted for the shutdown rewrite
On Sun, Jan 28, 2007 at 05:50:46PM +0100, Udo Richter wrote: > Hi list, > > I've finished a third version of the shutdown rewrite. Again there are > two patches available, one for VDR 1.5.0, and one with slight changes > for 1.4.x. > > http://www.udo-richter.de/vdr/patches.html#shutdown > http://www.udo-richter.de/vdr/patches.en.html#shutdown I have adapted my "relay" plugin for this patch. This plugin controls a solid-state relay via the TxD line of a serial port, so that the audio/video output equipment is powered off when the user is inactive. http://www.iki.fi/~msmakela/software/vdr/vdr-relay-0.1.0.tgz http://www.iki.fi/~msmakela/electronics/relay/index.en.html Example of usage: vdr -P'relay --relay=/dev/ttyS0' Note to Finnish users: the prototype relay box featured on the instructions page is for sale, because at a later point, I installed the relay inside the monitor to reduce the clutter of cables. Marko ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Capabilities
Bernd Juraschek wrote: > Hello, > > I've problems with my statusleds plugin. If vdr is not running as root > all capabilities are dropped - except the one for setting the system > time. > > My plugin wants to set the keyboard leds with the ioctl KDSETLED on > /dev/console. Unfortunately this ioctl requires one more capability. > > Is there any way to get this capability? Should we extend the plugin > interface with a possibility for the plugins to specify needed caps? > Why not simply document this fact in the installation guide: "The plugin must have write access to /dev/console." This is similar to the dvd or vcd plugin which need read/write access to /dev/dvd resp. /dev/cdrom. On my machine, I added the vdr user to the cdrom group. For /dev/console, this might be a bit trickier: I would have to add vdr to group tty AND give /dev/console rw-permissions for the group, but that should suffice. I don't know much about linux capabilities, but my feeling is, that they are meant for things not represented by devices (which use the simpler file-permissions model). Just my 2 cents, -- Patrick Cernko | mailto:[EMAIL PROTECTED] | http://www.errror.org "Wer HTML postet oder gepostetes HTML quotet oder sich gepostetes oder gequotetes HTML beschafft, um es in Verkehr zu bringen, wird geplonkt." (anonym) signature.asc Description: OpenPGP digital signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Capabilities
> Why not simply document this fact in the installation guide: > "The plugin must have write access to /dev/console." > This is similar to the dvd or vcd plugin which need read/write access to > /dev/dvd resp. /dev/cdrom. Hmm - this sounds like a good idea ... > On my machine, I added the vdr user to the cdrom group. For > /dev/console, this might be a bit trickier: I would have to add vdr to > group tty AND give /dev/console rw-permissions for the group, but that > should suffice. > > I don't know much about linux capabilities, but my feeling is, that they > are meant for things not represented by devices (which use the simpler > file-permissions model). On my system /dev/console has r/w access for anyone but this is not sufficient. I take a look into the kernel sources and there a two ways to get the right to modify terminals with ioctl(): - the modified terminal is the controlling terminal for the process or - the user has the capability to modify terminal settings What can we do now? Greetings, Bernd ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Capabilities
Bernd Juraschek wrote: >> I don't know much about linux capabilities, but my feeling is, that they >> are meant for things not represented by devices (which use the simpler >> file-permissions model). > > On my system /dev/console has r/w access for anyone but this is not > sufficient. Damn. so much about file-permissions in /dev. :-( > I take a look into the kernel sources and there a two ways > to get the right to modify terminals with ioctl(): > > - the modified terminal is the controlling terminal for the process or This is reflected by vdr's --terminal option. Are you sure, that you must ioctl /dev/CONSOLE or is any other tty sufficient, must it be a foreground tty or can it be a virtual screen not currently active, a pseudo tty (of screen, sshd, KDE-konsole)? In the case, all that works, I suggest adding a note to your documentation that the user MUST specify the --terminal option of vdr and us stdin/stdout/stderr as file-descriptors for the ioctl. > - the user has the capability to modify terminal settings > The Plugins are loaded long AFTER droping root rights, so I guess there is no safe way for a plugin to request additional permissions/capabilities. Maybe you can ask Klaus to also keep the terminal setting caps, or provide a small patch witch allows the user to do so when compiling vdr (or both ;-) ). So long, -- Patrick Cernko | mailto:[EMAIL PROTECTED] | http://www.errror.org "Wer HTML postet oder gepostetes HTML quotet oder sich gepostetes oder gequotetes HTML beschafft, um es in Verkehr zu bringen, wird geplonkt." (anonym) signature.asc Description: OpenPGP digital signature ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
Reinhard Nissl kirjoitti:
Hi,
Kartsa wrote:
Should I do both these changes at the same time or separately?
I think you may apply both changes at the same time.
Bye.
So I would like to raise this one up again. After applying the two
changes (dsyslog("TS continuity error (%d)", ccCounter) and { *FrameSize
= 0; dsyslog("cAudioRepacker: FrameSize == 0"); } in remux.c) I still
get these lines in log (and -l 3 in vdr startup)
vdr: [3600] cAudioRepacker(0xC0): skipped 232 bytes to sync on next
audio frame
vdr: [3600] cAudioRepacker(0xC0): skipped 240 bytes to sync on next
audio frame
vdr: [3600] cAudioRepacker(0xC0): skipped 492 bytes while syncing on
next audio frame
Why does these skipping of bytes appear?
And there still occurs AV sync problem from time to time.
\\Kartsa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, version 0.4
Hi list, I've finished a fourth version of the shutdown rewrite. Again there are two patches available, one for VDR 1.5.0, and one with slight changes for 1.4.x. http://www.udo-richter.de/vdr/patches.html#shutdown http://www.udo-richter.de/vdr/patches.en.html#shutdown Changes: - Renamed some identifiers: cSetup::NextWakeupEvent -> cSetup::NextWakeupTime cPlugin::NextWakeupEvent() -> cPlugin::WakeupTime() cPluginManager::GetNextWakeupEventPlugin() -> cPluginManager::GetNextWakeupPlugin() - Dropped running playback from the list of things that need confirmation on shutdown. Pressing power key while playback now shuts down just like in live mode. Automatic inactivity shutdown still wont happen while playback, since playback blocks housekeeping. - Handle setup menu restart questions in cShutdown::ConfirmRestart() - Do not handle setup menu restart as 'emergency exit' any more - Act differently on SIGHUP: Restart VDR like on setup menu restart, but dont ask questions. Do nothing if anything blocks restart. - The functionality of cThread::EmergencyExit(), vdr.c:ExitCode and vdr.c:Interrupted is now handled by cShutdown. - Shutdown.Exit(int) now stops the main loop and lets VDR return int as error level - cThread::EmergencyExit() remains as a wrapper - vdr.c:LastSignal partially replaces vdr.c:Interrupted - Dropped debug output from main loop - i18n strings added for German and Finnish: "VDR will shut down later - Press power to force" "VDR schaltet später aus - Nochmal zum erzwingen" "VDR sammuu myöhemmin - pakota virtakytkimellä" "VDR will shut down in %s minutes" ( note that %s will be something like 4:30 ) "VDR wird in %s Minuten ausschalten" "VDR sammuu %s minuutin kuluttua" "Editing - shut down anyway?" ( no longer cutting ;) ) "Schneide - trotzdem ausschalten?" "Leikkaus kesken - sammutetaanko?" "Plugin %s wakes up in %ld min, continue?" "Plugin %s wacht in %ld Min auf, weiter?" "Laajennos %s herää %ld minuutin kuluttua - sammutetaanko?" ( is this too long? ) "Editing - restart anyway?" "Schneide - trotzdem neu starten?" "Press any key to cancel restart" "Taste drücken, um Neustart abzubrechen" Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] runvdr extreme 0.2
Hi list, I've updated the runvdr extreme script to version 0.2. runvdr extreme is a runvdr script, just like the runvdr script included in the VDR distribution. Additionally, it supports configuration files, lots of command line options and more features. -> http://www.udo-richter.de/vdr/scripts.en.html#runvdr-extreme Fix: Several small fixes previously released as 0.1.1 New: Pass DVBLOAD and DVBUNLOAD to eval, this allows to add more than one line to these entries, or even complete small scripts. New: Load ~/.runvdr.conf as default, load /etc/runvdr.conf as fallback If you're not running as root, you can now redirect all file paths to your home directory. New: INCLUDE directive to load other config file For example, load a global config from the user config. New: -P "-plugin" drops plugin from plugin load list. Same for -D This allows to drop just one plugin but keep all the others. Change: LANGUAGE now sets LC_ALL, not LANG. LC_ALL has highest precedence. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [RFC] Shutdown rewrite for 1.5.x, version 0.4 - Finnish i18n
On Sun, Feb 18, 2007 at 10:09:54PM +0100, Udo Richter wrote:
> "Editing - shut down anyway?" ( no longer cutting ;) )
> "Schneide - trotzdem ausschalten?"
> "Leikkaus kesken - sammutetaanko?"
Hmm, this is inconsistent with most Finnish translations of
"editing" ("muokkaus") in i18n.c. I'd replace "Leikkaus" with
"Muokkaus".
> "Editing - restart anyway?"
> "Schneide - trotzdem neu starten?"
"Muokkaus kesken - käynnistetäänkö uudelleen?"
> "Press any key to cancel restart"
> "Taste drücken, um Neustart abzubrechen"
"Peru uudelleenkäynnistäminen painamalla mitä tahansa nappia"
Shouldn't it be "button" (Knopf) instead of "key" (Taste)? I would
guess that most people control vdr with a remote control unit instead
of a keyboard. Besides, "nappia" is shorter than "näppäintä" (as in
the Finnish translation of "Press any key to cancel shutdown").
Marko
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] FF card AV sync problems, possible fix to VDR (fwd)
Hi,
Kartsa wrote:
> So I would like to raise this one up again. After applying the two
> changes (dsyslog("TS continuity error (%d)", ccCounter) and { *FrameSize
> = 0; dsyslog("cAudioRepacker: FrameSize == 0"); } in remux.c) I still
> get these lines in log (and -l 3 in vdr startup)
>
> vdr: [3600] cAudioRepacker(0xC0): skipped 232 bytes to sync on next
> audio frame
> vdr: [3600] cAudioRepacker(0xC0): skipped 240 bytes to sync on next
> audio frame
> vdr: [3600] cAudioRepacker(0xC0): skipped 492 bytes while syncing on
> next audio frame
>
> Why does these skipping of bytes appear?
When do you get these lines?
They are OK just after starting a recording or starting transfer mode.
cAudioRepacker tries to suppress this message while initially syncing
but as the sync pattern is allowed to appear as audio frame data, it is
likely that cAudioRepacker get's in sync by mistake.
After having synced, cAudioRepacker uses the indicated frame length as a
guide when looking for the next audio packet. If the sync pattern isn't
found at the guided position, it will seek for it and report the number
of bytes skipped to find it.
This procedure is executed all over the time and once cAudioRepacker has
found a real sync pattern, the indicated frame length will guide
cAudioRepacker precisely to the next audio frame.
Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
