Francois-Xavier KOWALSKI wrote:
> Hello Klaus,
>
> find below a tip upon Dominique's request.
>
>> Subject:
>> [vdr] Process id in syslog
>> From:
>> Klaus Schmidinger <Klaus.Schmidinger(a)cadsoft.de>
>> Date:
>> Sat, 31 Dec 2005 15:12:24 +0100
>> To:
>> vdr(a)linuxtv.org
>>
>> To:
>> vdr(a)linuxtv.org
>>
>>
>> Before the conversion to NPTL, the syslog entries showed
>> the pid of each …
[View More]individual thread, so that it was easy to
>> tell which thread had issued a particular message.
>>
>> Now, with NPTL, all VDR syslog entries have the same pid,
>> which is that of the foreground thread. This is pretty
>> useless, because in case of a problem it's important
>> to know exactly which thread has issued which message.
>>
>> Since I couldn't find any information on this, maybe somebody
>> here knows how openlog() needs to be called in order to have
>> the individual thread pids displayed in syslog messages on
>> an NPTL system.
>>
>>
> Whatever pthread implementation is in use, the symlink /proc/self always
> refers to the LWPID (Light-Weight Process ID, i.e. thread PID in your
> case). I suggest -- this is what I do -- to stat(2) /proc/self refered
> file & sscanf(3) it. Of course, this is better to be done & stored (e.g.
> in TLS) at the thread startup & then re-used upon need.
Well, this isn't exactly what I meant.
I do have the right pids in my program.
What I want is that a call like
openlog("vdr", LOG_PID | LOG_CONS, LOG_USER);
followed by
syslog(LOG_INFO, "some log message");
writes to the log file
Jan 7 12:25:52 video vdr[7457]: some log message
where [7457] should be the pid of the actual thread, not that
of the main thread.
For instance, on a non-NPTL system, the log looks like this:
Dec 10 14:38:51 video vdr[709]: VDR version 1.3.38 started
Dec 10 14:38:51 video vdr[709]: loading /video/setup.conf
...
Dec 10 14:38:51 video vdr[711]: video directory scanner thread started (pid=711, tid=711)
while on an NPTL system I get:
Jan 7 12:25:51 video vdr[7457]: VDR version 1.3.38 started
Jan 7 12:25:51 video vdr[7457]: loading /video/setup.conf
...
Jan 7 12:25:52 video vdr[7457]: video directory scanner thread started (pid=7457, tid=7459)
As you can see, in the first case there is vdr[709] for the main thread
and vdr[711] for the second thread. In the second case there is vdr[7457]
for both threads, while I would like the second thread to show vdr[7459].
Here's a manually created example of how this should look:
Jan 7 12:25:51 video vdr[7457]: VDR version 1.3.38 started
Jan 7 12:25:51 video vdr[7457]: loading /video/setup.conf
...
Jan 7 12:25:52 video vdr[7459]: video directory scanner thread started (pid=7457, tid=7459)
Klaus
[View Less]
Hello,
A few of the channels I can receive broadcast incorrect data. (Eg
satellite data where nid is not unique across the whole satellite. I
also have a terrestrial channel that does not broadcast the correct
frequency).
What I do in this situation is use rid. There is one problem:
Even with rid!=0, the channel will still be updated by vdr. So, to fix
the channel I have to have two versions.
The first with rid=0 which vdr updates and installs the incorrect data.
The second has rid=1 …
[View More]which vdr leaves alone.
Now: given that rid!=0 will never be set by a scan, I think it would be
better if vdr just left all rid!=0 channels alone. This way rid could
indicate "don't auto update". This behaviour would not affect the other
use of rid.
Now, I know some people are going to say "get the broadcasters to fix
it"..., but I don't think that is a reason not to make this change.
[View Less]
Hi Rolf,
Usually you have your patch a few hours after the release of a new VDR ready
:) Thanks for that. Today i can only find your ttxtsubs and other patches
for 1.3.38. The version 2.8 of 1.3.37 gives me to much rejects. Any ETA ?
Thanks anyway for your work....
/hgm.bg
Hi,
are there any changes if lirc and terminal are used in common?
While menu key works on remote control, it no longer works on keyboard
(I use F12 for that).
1.3.37 works fine.
Any hints available?
Thank you,
Peter
Hi all,
I'm running vdr 1.3.37, I am currently using cvs version of streamdev.
I'm running Xine 0.7.6.
On the slave machine I start up vdr with ./vdr -P'xine -r'
-Pstreamdev-client
It starts up, connects to the backend no problem and gets the last
channel it was on and shows video. So initial communication works.
When I attempt to change channels, I no longer get video. I can see the
channel flip on the backend but nothing on the client.
1) is there any way I can increase debugging …
[View More]output to tell me where
exactly the problem seems to be?
2) Has anyone else seen this and got it resolved?
My output is:
SetAudioChannelDevice: 0
SetPlayMode: 1
SetPlayMode: 0
SetAudioChannelDevice: 0
SetPlayMode: 1
[vVMMMSetDigitalAudioDevice: 0
SetAudioChannelDevice: 0
aA+7+8+12+14+15+17+19+22] buffered 21.5 frames
SetPlayMode: 0
SetAudioChannelDevice: 0
SetPlayMode: 1
SetPlayMode: 0
SetAudioChannelDevice: 0
SetPlayMode: 1
SetPlayMode: 0
SetAudioChannelDevice: 0
SetPlayMode: 1
SetPlayMode: 0
SetAudioChannelDevice: 0
SetPlayMode: 1
vdr-xine: Client disconnected!
SetPlayMode: 0
[View Less]
As per the subject, if the teletext subtitles are active during replay
it's impossible to select the menu. The attached patch fixes it but I
don't know it it may have other adverse effects (it doesn't seems so here).
Bye
--
- Yo también quiero una Europa libre de Patentes de Software -
- I want a Software Patents Free Europe too! And you? -
---------------------------------------------------------------
EuropeSwPatentFree - http://EuropeSwPatentFree.hispalinux.es
Hi,
from my log:
Jan 7 23:36:32 mm vdr[3539]: timer 1 (1 2240-0045 'James Bond 007 - Der Hauch des Todes') start
Jan 7 23:36:32 mm vdr[3539]: record /vdr/video/James_Bond_007_-_Der_Hauch_des_Todes/2006-01-07.23.30.50.99.rec
Jan 8 00:02:22 mm vdr[3539]: replay /vdr/video/James_Bond_007_-_Der_Hauch_des_Todes/2006-01-07.23.30.50.99.rec
Jan 8 01:00:43 mm vdr[3544]: channel 1 (Das Erste) event 23:35 'James Bond 007 - Der Hauch des Todes' status 1
Jan 8 01:00:44 mm vdr[3539]: timer 1 (1 2240-…
[View More]0045 'James Bond 007 - Der Hauch des Todes') stop
Jan 8 01:41:51 mm vdr[3544]: channel 1 (Das Erste) event 01:40 'Tagesschau' status 4
01:00 is about the time when the programm SHOULD have stopped.
It SHOULD have started at 22:40, EPG said so. But it really started at 23:35.
VPS start was correct, but the end went wrong, it stopped about 1 hour too early. Normally
it seems the time between status 1 and the next status 4 is quite short, here it was 41 minutes.
Would it be possible to change the messages status 1 etc into something more verbose?
And maybe it would help not to stop a timer before the EPG length of the program has passed, no matter
what the status says.
--
Wolfgang
[View Less]
Hi
a new version of plugin channelscan has been released. Channelscan uses
a transponders .ini file from win project like prog-DVB software for
create a channels.conf
The homepage of the plugin is at http://www.kikko77.altervista.org goto
download page for the get it
---------------------------------------------------------------------------------------------------------
2006-01-08: Version 0.0.5a
- Add finnish translaction (from www.gentoo.de)
- Add menuitem patch (from www.gentoo.de)…
[View More]
*** Thanks for all patch, but in future if anyone want to send me it, i
release a
new version of plugin, so all vdr user have a lot benefits. ***
[View Less]