Hi,
since VDR became subtitles aware some months ago, I have been getting this kind of entries in the log:
Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9
PID 2027 is for a finnish subtitles stream.
I cannot see anything failing or such when this entry appears, but just thought to let Klaus know about it, in case it would make some sense to him.
Here is a longer snippet of the log around that time:
Jan 6 23:00:36 vdr vdr: [7319] subtitleConverter thread started (pid=4506, tid=7319) Jan 6 23:02:31 vdr vdr: [4513] channel 1 (TV1) event Su 06.01.2008 23:05-23:28 'Ponille kyytiä' status 4 Jan 6 23:02:47 vdr vdr: [4513] changing pids of channel 2 from 513+513:660=fin:2027=fin,2028=dut:2321 to 513+513:660=fin:2027=fin:2321 Jan 6 23:02:47 vdr vdr: [4506] retuning due to modification of channel 2 Jan 6 23:02:47 vdr vdr: [4506] switching to channel 2 Jan 6 23:02:47 vdr vdr: [7257] transfer thread ended (pid=4506, tid=7257) Jan 6 23:02:47 vdr vdr: [7319] subtitleConverter thread ended (pid=4506, tid=7319) Jan 6 23:02:47 vdr vdr: [4506] buffer stats: 110920 (5%) used Jan 6 23:02:48 vdr vdr: [4506] buffer stats: 0 (0%) used Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9 Jan 6 23:02:48 vdr vdr: [7340] transfer thread started (pid=4506, tid=7340) Jan 6 23:02:49 vdr vdr: [4506] buffer stats: 0 (0%) used
-Petri
Hi,
Petri Helin schrieb:
since VDR became subtitles aware some months ago, I have been getting this kind of entries in the log:
Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9
PID 2027 is for a finnish subtitles stream.
I cannot see anything failing or such when this entry appears, but just thought to let Klaus know about it, in case it would make some sense to him.
I came across this log message today, too. Looks like SetCurrentSubtitleTrack() calls AttachReceiver() on the PrimaryDevice() which is cXineDevice in my case.
(gdb) bt #0 0x080bbabb in cDevice::AddPid (this=0xb44c49f8, Pid=131, PidType=ptOther) at device.c:612 #1 0x080bbc00 in cDevice::AttachReceiver (this=0xb44c49f8, Receiver=0xb44e2078) at device.c:1502 #2 0x080be272 in cDevice::SetCurrentSubtitleTrack (this=0xb44c49f8, Type=ttSubtitle, Manual=false) at device.c:1052 #3 0x080be3b4 in cDevice::EnsureSubtitleTrack (this=0xb44c49f8) at device.c:1104 #4 0x080be58d in cDevice::SetAvailableTrack (this=0xb44c49f8, Type=ttSubtitle, Index=0, Id=131, Language=0x82529c8 "deu", Description=0x0) at device.c:984 #5 0x080bf0cb in cDevice::SetChannel (this=0xb44c49f8, Channel=0x82526c8, LiveView=true) at device.c:845 #6 0x080bf1ae in cDevice::SwitchChannel (this=0xb44c49f8, Channel=0x82526c8, LiveView=true) at device.c:735 #7 0x080a59bd in cChannels::SwitchTo (this=0x81a9880, Number=2) at channels.c:1201 #8 0x08158988 in main (argc=14, argv=0xbf993d34) at vdr.c:762
Looks like Transferring() isn't set at that time and therefore a cLiveSubtitle instance is created although none is needed in transfer mode (which is the only way how my setup works).
1048 if (currentSubtitleTrack != ttNone && !Replaying() && !Transferring()) { 1049 const tTrackId *TrackId = GetTrack(currentSubtitleTrack); 1050 if (TrackId && TrackId->id) { 1051 liveSubtitle = new cLiveSubtitle(TrackId->id); 1052 AttachReceiver(liveSubtitle); 1053 } 1054 }
Bye.
On 01/06/08 23:57, Reinhard Nissl wrote:
Hi,
Petri Helin schrieb:
since VDR became subtitles aware some months ago, I have been getting this kind of entries in the log:
Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9
PID 2027 is for a finnish subtitles stream.
I cannot see anything failing or such when this entry appears, but just thought to let Klaus know about it, in case it would make some sense to him.
I came across this log message today, too. Looks like SetCurrentSubtitleTrack() calls AttachReceiver() on the PrimaryDevice() which is cXineDevice in my case.
(gdb) bt #0 0x080bbabb in cDevice::AddPid (this=0xb44c49f8, Pid=131, PidType=ptOther) at device.c:612 #1 0x080bbc00 in cDevice::AttachReceiver (this=0xb44c49f8, Receiver=0xb44e2078) at device.c:1502 #2 0x080be272 in cDevice::SetCurrentSubtitleTrack (this=0xb44c49f8, Type=ttSubtitle, Manual=false) at device.c:1052 #3 0x080be3b4 in cDevice::EnsureSubtitleTrack (this=0xb44c49f8) at device.c:1104 #4 0x080be58d in cDevice::SetAvailableTrack (this=0xb44c49f8, Type=ttSubtitle, Index=0, Id=131, Language=0x82529c8 "deu", Description=0x0) at device.c:984 #5 0x080bf0cb in cDevice::SetChannel (this=0xb44c49f8, Channel=0x82526c8, LiveView=true) at device.c:845 #6 0x080bf1ae in cDevice::SwitchChannel (this=0xb44c49f8, Channel=0x82526c8, LiveView=true) at device.c:735 #7 0x080a59bd in cChannels::SwitchTo (this=0x81a9880, Number=2) at channels.c:1201 #8 0x08158988 in main (argc=14, argv=0xbf993d34) at vdr.c:762
Looks like Transferring() isn't set at that time and therefore a cLiveSubtitle instance is created although none is needed in transfer mode (which is the only way how my setup works).
1048 if (currentSubtitleTrack != ttNone && !Replaying() && !Transferring()) { 1049 const tTrackId *TrackId = GetTrack(currentSubtitleTrack); 1050 if (TrackId && TrackId->id) { 1051 liveSubtitle = new cLiveSubtitle(TrackId->id); 1052 AttachReceiver(liveSubtitle); 1053 } 1054 }
SetChannel() in live mode triggers a Transfer-Mode, but that is actually only started after SetChannel() has ended. Therefore, as you correctly pointed out, Transferring is not yet set in EnsureSubtitleTrack().
Maybe the sequence
if (!NeedsTransferMode) EnsureAudioTrack(true); EnsureSubtitleTrack();
should be changed to
if (!NeedsTransferMode) { EnsureAudioTrack(true); EnsureSubtitleTrack(); }
Could you please test this?
Klaus
On 02/09/08 16:36, Klaus Schmidinger wrote:
On 01/06/08 23:57, Reinhard Nissl wrote:
Hi,
Petri Helin schrieb:
since VDR became subtitles aware some months ago, I have been getting this kind of entries in the log:
Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9
PID 2027 is for a finnish subtitles stream.
I cannot see anything failing or such when this entry appears, but just thought to let Klaus know about it, in case it would make some sense to him.
I came across this log message today, too. Looks like SetCurrentSubtitleTrack() calls AttachReceiver() on the PrimaryDevice() which is cXineDevice in my case.
(gdb) bt #0 0x080bbabb in cDevice::AddPid (this=0xb44c49f8, Pid=131, PidType=ptOther) at device.c:612 #1 0x080bbc00 in cDevice::AttachReceiver (this=0xb44c49f8, Receiver=0xb44e2078) at device.c:1502 #2 0x080be272 in cDevice::SetCurrentSubtitleTrack (this=0xb44c49f8, Type=ttSubtitle, Manual=false) at device.c:1052 #3 0x080be3b4 in cDevice::EnsureSubtitleTrack (this=0xb44c49f8) at device.c:1104 #4 0x080be58d in cDevice::SetAvailableTrack (this=0xb44c49f8, Type=ttSubtitle, Index=0, Id=131, Language=0x82529c8 "deu", Description=0x0) at device.c:984 #5 0x080bf0cb in cDevice::SetChannel (this=0xb44c49f8, Channel=0x82526c8, LiveView=true) at device.c:845 #6 0x080bf1ae in cDevice::SwitchChannel (this=0xb44c49f8, Channel=0x82526c8, LiveView=true) at device.c:735 #7 0x080a59bd in cChannels::SwitchTo (this=0x81a9880, Number=2) at channels.c:1201 #8 0x08158988 in main (argc=14, argv=0xbf993d34) at vdr.c:762
Looks like Transferring() isn't set at that time and therefore a cLiveSubtitle instance is created although none is needed in transfer mode (which is the only way how my setup works).
1048 if (currentSubtitleTrack != ttNone && !Replaying() && !Transferring()) { 1049 const tTrackId *TrackId = GetTrack(currentSubtitleTrack); 1050 if (TrackId && TrackId->id) { 1051 liveSubtitle = new cLiveSubtitle(TrackId->id); 1052 AttachReceiver(liveSubtitle); 1053 } 1054 }
SetChannel() in live mode triggers a Transfer-Mode, but that is actually only started after SetChannel() has ended. Therefore, as you correctly pointed out, Transferring is not yet set in EnsureSubtitleTrack().
Maybe the sequence
if (!NeedsTransferMode) EnsureAudioTrack(true); EnsureSubtitleTrack();
should be changed to
if (!NeedsTransferMode) { EnsureAudioTrack(true); EnsureSubtitleTrack(); }
Could you please test this?
Klaus
Still waiting for verification.
Klaus
Klaus Schmidinger wrote:
On 02/09/08 16:36, Klaus Schmidinger wrote:
On 01/06/08 23:57, Reinhard Nissl wrote:
Hi,
Petri Helin schrieb:
since VDR became subtitles aware some months ago, I have been getting this kind of entries in the log:
Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9
PID 2027 is for a finnish subtitles stream.
I cannot see anything failing or such when this entry appears, but just thought to let Klaus know about it, in case it would make some sense to him.
I came across this log message today, too. Looks like SetCurrentSubtitleTrack() calls AttachReceiver() on the PrimaryDevice() which is cXineDevice in my case.
(gdb) bt #0 0x080bbabb in cDevice::AddPid (this=0xb44c49f8, Pid=131, PidType=ptOther) at device.c:612 #1 0x080bbc00 in cDevice::AttachReceiver (this=0xb44c49f8, Receiver=0xb44e2078) at device.c:1502 #2 0x080be272 in cDevice::SetCurrentSubtitleTrack (this=0xb44c49f8, Type=ttSubtitle, Manual=false) at device.c:1052 #3 0x080be3b4 in cDevice::EnsureSubtitleTrack (this=0xb44c49f8) at device.c:1104 #4 0x080be58d in cDevice::SetAvailableTrack (this=0xb44c49f8, Type=ttSubtitle, Index=0, Id=131, Language=0x82529c8 "deu", Description=0x0) at device.c:984 #5 0x080bf0cb in cDevice::SetChannel (this=0xb44c49f8, Channel=0x82526c8, LiveView=true) at device.c:845 #6 0x080bf1ae in cDevice::SwitchChannel (this=0xb44c49f8, Channel=0x82526c8, LiveView=true) at device.c:735 #7 0x080a59bd in cChannels::SwitchTo (this=0x81a9880, Number=2) at channels.c:1201 #8 0x08158988 in main (argc=14, argv=0xbf993d34) at vdr.c:762
Looks like Transferring() isn't set at that time and therefore a cLiveSubtitle instance is created although none is needed in transfer mode (which is the only way how my setup works).
1048 if (currentSubtitleTrack != ttNone && !Replaying() && !Transferring()) { 1049 const tTrackId *TrackId = GetTrack(currentSubtitleTrack); 1050 if (TrackId && TrackId->id) { 1051 liveSubtitle = new cLiveSubtitle(TrackId->id); 1052 AttachReceiver(liveSubtitle); 1053 } 1054 }
SetChannel() in live mode triggers a Transfer-Mode, but that is actually only started after SetChannel() has ended. Therefore, as you correctly pointed out, Transferring is not yet set in EnsureSubtitleTrack().
Maybe the sequence
if (!NeedsTransferMode) EnsureAudioTrack(true); EnsureSubtitleTrack();
should be changed to
if (!NeedsTransferMode) { EnsureAudioTrack(true); EnsureSubtitleTrack(); }
Could you please test this?
Klaus
Still waiting for verification.
Sorry, had forgotten this... I made the change you suggested in device.c, but I am still seeing the error message.
-Petri
On 02/16/08 17:46, Petri Helin wrote:
Klaus Schmidinger wrote:
On 02/09/08 16:36, Klaus Schmidinger wrote:
On 01/06/08 23:57, Reinhard Nissl wrote:
Hi,
Petri Helin schrieb:
since VDR became subtitles aware some months ago, I have been getting this kind of entries in the log:
Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9
PID 2027 is for a finnish subtitles stream.
I cannot see anything failing or such when this entry appears, but just thought to let Klaus know about it, in case it would make some sense to him.
I came across this log message today, too. Looks like SetCurrentSubtitleTrack() calls AttachReceiver() on the PrimaryDevice() which is cXineDevice in my case.
(gdb) bt #0 0x080bbabb in cDevice::AddPid (this=0xb44c49f8, Pid=131, PidType=ptOther) at device.c:612 #1 0x080bbc00 in cDevice::AttachReceiver (this=0xb44c49f8, Receiver=0xb44e2078) at device.c:1502 #2 0x080be272 in cDevice::SetCurrentSubtitleTrack (this=0xb44c49f8, Type=ttSubtitle, Manual=false) at device.c:1052 #3 0x080be3b4 in cDevice::EnsureSubtitleTrack (this=0xb44c49f8) at device.c:1104 #4 0x080be58d in cDevice::SetAvailableTrack (this=0xb44c49f8, Type=ttSubtitle, Index=0, Id=131, Language=0x82529c8 "deu", Description=0x0) at device.c:984 #5 0x080bf0cb in cDevice::SetChannel (this=0xb44c49f8, Channel=0x82526c8, LiveView=true) at device.c:845 #6 0x080bf1ae in cDevice::SwitchChannel (this=0xb44c49f8, Channel=0x82526c8, LiveView=true) at device.c:735 #7 0x080a59bd in cChannels::SwitchTo (this=0x81a9880, Number=2) at channels.c:1201 #8 0x08158988 in main (argc=14, argv=0xbf993d34) at vdr.c:762
Looks like Transferring() isn't set at that time and therefore a cLiveSubtitle instance is created although none is needed in transfer mode (which is the only way how my setup works).
1048 if (currentSubtitleTrack != ttNone && !Replaying() && !Transferring()) { 1049 const tTrackId *TrackId = GetTrack(currentSubtitleTrack); 1050 if (TrackId && TrackId->id) { 1051 liveSubtitle = new cLiveSubtitle(TrackId->id); 1052 AttachReceiver(liveSubtitle); 1053 } 1054 }
SetChannel() in live mode triggers a Transfer-Mode, but that is actually only started after SetChannel() has ended. Therefore, as you correctly pointed out, Transferring is not yet set in EnsureSubtitleTrack().
Maybe the sequence
if (!NeedsTransferMode) EnsureAudioTrack(true); EnsureSubtitleTrack();
should be changed to
if (!NeedsTransferMode) { EnsureAudioTrack(true); EnsureSubtitleTrack(); }
Could you please test this?
Klaus
Still waiting for verification.
Sorry, had forgotten this... I made the change you suggested in device.c, but I am still seeing the error message.
I believe this should fix it:
--- device.c 2008/02/16 13:52:11 1.153 +++ device.c 2008/02/17 15:40:08 @@ -1049,7 +1049,7 @@ const tTrackId *TrackId = GetTrack(currentSubtitleTrack); if (TrackId && TrackId->id) { liveSubtitle = new cLiveSubtitle(TrackId->id); - AttachReceiver(liveSubtitle); + ActualDevice()->AttachReceiver(liveSubtitle); } } return true;
Klaus
On 02/17/08 16:41, Klaus Schmidinger wrote:
On 02/16/08 17:46, Petri Helin wrote:
Klaus Schmidinger wrote:
On 02/09/08 16:36, Klaus Schmidinger wrote:
On 01/06/08 23:57, Reinhard Nissl wrote:
Hi,
Petri Helin schrieb:
since VDR became subtitles aware some months ago, I have been getting this kind of entries in the log:
Jan 6 23:02:48 vdr vdr: [4506] ERROR: can't set PID 2027 on device 9
PID 2027 is for a finnish subtitles stream.
I cannot see anything failing or such when this entry appears, but just thought to let Klaus know about it, in case it would make some sense to him.
I came across this log message today, too. Looks like SetCurrentSubtitleTrack() calls AttachReceiver() on the PrimaryDevice() which is cXineDevice in my case.
(gdb) bt #0 0x080bbabb in cDevice::AddPid (this=0xb44c49f8, Pid=131, PidType=ptOther) at device.c:612 #1 0x080bbc00 in cDevice::AttachReceiver (this=0xb44c49f8, Receiver=0xb44e2078) at device.c:1502 #2 0x080be272 in cDevice::SetCurrentSubtitleTrack (this=0xb44c49f8, Type=ttSubtitle, Manual=false) at device.c:1052 #3 0x080be3b4 in cDevice::EnsureSubtitleTrack (this=0xb44c49f8) at device.c:1104 #4 0x080be58d in cDevice::SetAvailableTrack (this=0xb44c49f8, Type=ttSubtitle, Index=0, Id=131, Language=0x82529c8 "deu", Description=0x0) at device.c:984 #5 0x080bf0cb in cDevice::SetChannel (this=0xb44c49f8, Channel=0x82526c8, LiveView=true) at device.c:845 #6 0x080bf1ae in cDevice::SwitchChannel (this=0xb44c49f8, Channel=0x82526c8, LiveView=true) at device.c:735 #7 0x080a59bd in cChannels::SwitchTo (this=0x81a9880, Number=2) at channels.c:1201 #8 0x08158988 in main (argc=14, argv=0xbf993d34) at vdr.c:762
Looks like Transferring() isn't set at that time and therefore a cLiveSubtitle instance is created although none is needed in transfer mode (which is the only way how my setup works).
1048 if (currentSubtitleTrack != ttNone && !Replaying() && !Transferring()) { 1049 const tTrackId *TrackId = GetTrack(currentSubtitleTrack); 1050 if (TrackId && TrackId->id) { 1051 liveSubtitle = new cLiveSubtitle(TrackId->id); 1052 AttachReceiver(liveSubtitle); 1053 } 1054 }
SetChannel() in live mode triggers a Transfer-Mode, but that is actually only started after SetChannel() has ended. Therefore, as you correctly pointed out, Transferring is not yet set in EnsureSubtitleTrack().
Maybe the sequence
if (!NeedsTransferMode) EnsureAudioTrack(true); EnsureSubtitleTrack();
should be changed to
if (!NeedsTransferMode) { EnsureAudioTrack(true); EnsureSubtitleTrack(); }
Could you please test this?
Klaus
Still waiting for verification.
Sorry, had forgotten this... I made the change you suggested in device.c, but I am still seeing the error message.
I believe this should fix it:
--- device.c 2008/02/16 13:52:11 1.153 +++ device.c 2008/02/17 15:40:08 @@ -1049,7 +1049,7 @@ const tTrackId *TrackId = GetTrack(currentSubtitleTrack); if (TrackId && TrackId->id) { liveSubtitle = new cLiveSubtitle(TrackId->id);
AttachReceiver(liveSubtitle);
ActualDevice()->AttachReceiver(liveSubtitle); } } return true;
Forget that - VDR is in Transfer-Mode in your case, so setting any additional PID and starting the cLiveSubtitle is just wrong.
The basic problem, as Reinhard pointed out, is that Transferring() doesn't return the right value at this time, because the transfer player hasn't been attached, yet.
This change determines the Transferring condition from the fact that the actual device is different than the primary device, which is already the case at this early stage:
--- device.c 2008/02/16 13:52:11 1.153 +++ device.c 2008/02/17 15:55:06 @@ -1159,7 +1159,7 @@
bool cDevice::Transferring(void) const { - return dynamic_cast<cTransfer *>(player) != NULL; + return ActualDevice() != PrimaryDevice(); }
bool cDevice::AttachPlayer(cPlayer *Player)
I hope this doesn't have any other side effects...
Klaus
Hi,
Klaus Schmidinger schrieb:
The basic problem, as Reinhard pointed out, is that Transferring() doesn't return the right value at this time, because the transfer player hasn't been attached, yet.
This change determines the Transferring condition from the fact that the actual device is different than the primary device, which is already the case at this early stage:
--- device.c 2008/02/16 13:52:11 1.153 +++ device.c 2008/02/17 15:55:06 @@ -1159,7 +1159,7 @@
bool cDevice::Transferring(void) const {
- return dynamic_cast<cTransfer *>(player) != NULL;
- return ActualDevice() != PrimaryDevice();
}
bool cDevice::AttachPlayer(cPlayer *Player)
I hope this doesn't have any other side effects...
Hmm, this might break vdr-xine. I remember a discussion which led to the introduction of cDevice::Transferring(), but I'm not sure whether I was using the same code before, which is now used to implement this function.
As I'm currently busy with other things, I won't find time to test this change the next days.
Bye.
On 02/17/08 18:31, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
The basic problem, as Reinhard pointed out, is that Transferring() doesn't return the right value at this time, because the transfer player hasn't been attached, yet.
This change determines the Transferring condition from the fact that the actual device is different than the primary device, which is already the case at this early stage:
--- device.c 2008/02/16 13:52:11 1.153 +++ device.c 2008/02/17 15:55:06 @@ -1159,7 +1159,7 @@
bool cDevice::Transferring(void) const {
- return dynamic_cast<cTransfer *>(player) != NULL;
- return ActualDevice() != PrimaryDevice();
}
bool cDevice::AttachPlayer(cPlayer *Player)
I hope this doesn't have any other side effects...
Hmm, this might break vdr-xine. I remember a discussion which led to the introduction of cDevice::Transferring(), but I'm not sure whether I was using the same code before, which is now used to implement this function.
As I'm currently busy with other things, I won't find time to test this change the next days.
Can somebody else with vdr-xine please test whether this works?
Although I don't see how this change could affect vdr-xine. But it should be checked, anyway.
Klaus
Klaus Schmidinger wrote:
On 02/17/08 18:31, Reinhard Nissl wrote:
Hi,
Klaus Schmidinger schrieb:
The basic problem, as Reinhard pointed out, is that Transferring() doesn't return the right value at this time, because the transfer player hasn't been attached, yet.
This change determines the Transferring condition from the fact that the actual device is different than the primary device, which is already the case at this early stage:
--- device.c 2008/02/16 13:52:11 1.153 +++ device.c 2008/02/17 15:55:06 @@ -1159,7 +1159,7 @@
bool cDevice::Transferring(void) const {
- return dynamic_cast<cTransfer *>(player) != NULL;
- return ActualDevice() != PrimaryDevice();
}
bool cDevice::AttachPlayer(cPlayer *Player)
I hope this doesn't have any other side effects...
Hmm, this might break vdr-xine. I remember a discussion which led to the introduction of cDevice::Transferring(), but I'm not sure whether I was using the same code before, which is now used to implement this function.
As I'm currently busy with other things, I won't find time to test this change the next days.
Can somebody else with vdr-xine please test whether this works?
Although I don't see how this change could affect vdr-xine. But it should be checked, anyway.
I have tested this with xineliboutput and have not encountered any problems. And it seems to have also fixed whatever it was that was causing the error messages.
-Petri