Re: [vdr] demuxing subtitles with projectx
Petri Helin [EMAIL PROTECTED] wrote: I noticed that Project-X is able to handle only subtitles within subID 0x20. I have a recording with subtitles with subIDs 0x20 and 0x21 and demuxing fails with command 248. If I restrict Project-X to subID 0x20, I am able to demux that recording too. Unfortunately this means that the second subtitle stream cannot be demuxed. Is this related to the TODO Klaus has marked for 0x21 in dvbsubtitle.c? can anyone provide dvb.matt from http://forum.dvbtechnics.info a little part of recording with 2 or more subtitle streams? so we can get a version of projectx thet supports more than one dvb-streams. stefan ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] VDR developer version 1.5.15
VDR developer version 1.5.15 is now available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.15.tar.bz2 A 'diff' against the previous developer version is available at ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.5.14-1.5.15.diff NOTE: = This is the final step towards a stable version 1.6.0. Please report any bugs as soon as possible, so that I can prepare a release candidate next weekend. If nothing unexpected happens, I plan to release version 1.6.0 on March 2. WARNING: This is a *developer* version. Even though *I* use it in my productive environment, I strongly recommend that you only use it under controlled conditions and for testing and debugging. The changes since version 1.5.14: - Updated the Italian OSD texts (thanks to Diego Pierotto). - Added option -i to the pictures plugin's pic2mpg to ignore unknown file types. - Revoked the switch to the multiproto driver in order to make a new stable version before making this big switch and forcing all users to install a driver that is not yet in the kernel source. The removed code will reappear in version 1.7.0. Note that you may need to switch back to an older version of your channels.conf file if you have already used version 1.5.14, because it introduced new parameters. - Added the new command line option --userdump to enable core dumps in case VDR is run as root with option -u (thanks to Hans-Werner Hilse). - Speeded up anti-aliased font rendering by caching the blend indexes (based on a suggestion by Martin Wache). - Fixed setting the OSD area in the pictures plugin. - Ignoring repeat and release keys in the time search entry mode during replay, to avoid inadvertently leaving it in case a key is pressed too long (suggested by Andreas Brugger). - Improved sending all frames to devices that can handle them in fast forward trick speeds, including subtitles (thanks to Timo Eskola). - The section handler is now stopped before the device is destroyed, to avoid accessing file handles after they have become invalid (thanks to Reinhard Nissl for reporting an invalid access when ending VDR, and to Deti Fliegl for a patch that was used to implement StopSectionHandler()). - Fixed setting the date in the channel display of the classic and sttng skins, to avoid unnecessary OSD access (thanks to Marco Schlüßler). - The free disk space is now also displayed in the title of the Recordings menu (suggested by Walter Koch). - Changed the message Upcoming VPS recording! to Upcoming recording! because it applies to non-VPS recordings as well. - Fixed a loss of a timer's 'recording' flag after modifying it via MODT. - Fixed detecting directories in cFileNameList::Load(). - Running the thread that removes deleted recordings at a low priority to (maybe) avoid stuttering replay in case the thread is run during replay. - Limiting the length of the recording name in timers in case VDR is run with --vfat, in order to avoid names that are too long for Windows (suggested by Rolf Ahrenberg). - Using cString::sprintf() instead of asprintf() (thanks to Wolfgang Rohdewald for pointing out a possible problem if the return value is not checked). Plugin authors may want to consider doing the same. For convenience there is now an additional version of cString::sprintf() that accepts a va_list parameter. - When deleting the recording that is currently replayed, the replay is now stopped immediately (thanks to Mikko Matilainen for reporting a possible crash if the Info key is pressed after deleting the currently replayed recording). - Updated the Russian OSD texts (thanks to Oleg Roitburd). - When determining the amount of free disk space, any deleted (but not yet removed) recordings on different file systems (that are mounted under the video directory) are no longer taken into account. - When running out of disk space during a recording, only such deleted or old recordings are removed, that actually are on the video directory file system(s). This prevents VDR from accidentally deleting recordings on other file systems, which would not add any free space to the video directory. - Implemented the cStatus, cDevice and cPlayer functions for setting subtitle tracks in plugins (thanks to Petri Hintukainen). - Added cStatus::TimerChange() to inform plugins about changes to the list of timers (based on a patch from Benedikt Elser). - Added new cStatus functions to the 'status' plugin. - Added missing #include limits.h to epg.c and menuitems.h (thanks to Ville Skyttä). - The new function cSkin::SetScrollbar() can be implemented by skins to display a scrollbar in every list menu. The 'classic' and 'sttng' skins have been changed accordingly, as well as the 'skincurses' plugin. - Introduced 'operator const void * ()' in cString to catch cases where operator*() should be used. - Fixed calculating the scrollbar sizes in the skins. The changes regarding the handling of deleted recordings
Re: [vdr] Trouble with vdrportal.de?
On 02/17/08 15:50, Klaus Schmidinger wrote: Is it just me, or is there some trouble with vdrportal.de? All I get is !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//ENhtmlheadtitle/title/headbody/body/html which results in an empty page. Apparently my bookmark contained vdrportal.de, which seems to not work any more. After changing it to www.vdr-portal.de everything is fine again. Sorry 'bout the noise. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Trouble with vdrportal.de?
On 02/17/08 15:55, Klaus Schmidinger wrote: On 02/17/08 15:50, Klaus Schmidinger wrote: Is it just me, or is there some trouble with vdrportal.de? All I get is !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//ENhtmlheadtitle/title/headbody/body/html which results in an empty page. Apparently my bookmark contained vdrportal.de, which seems to not work Actually it was vdr-portal.de that didn't work. Sorry, I'm apparently confused today... Klaus any more. After changing it to www.vdr-portal.de everything is fine again. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Trouble with vdrportal.de?
Is it just me, or is there some trouble with vdrportal.de? All I get is !DOCTYPE html PUBLIC -//W3C//DTD HTML 4.01 Transitional//ENhtmlheadtitle/title/headbody/body/html which results in an empty page. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR developer version 1.5.15 - compilation warnings
Compiling the new version on my 64-bit AMD processor produces the warnings below. I think they've probably been there for a while, I don't usually watch VDR compiling... # g++ -v Using built-in specs. Target: x86_64-mandriva-linux-gnu Configured with: ../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --enable-checking=release --enable-languages=c,c++,ada,fortran,objc,obj-c++,java --host=x86_64-mandriva-linux-gnu --with-cpu=generic --with-system-zlib --enable-threads=posix --enable-shared --enable-long-long --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --enable-java-awt=gtk --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --enable-gtk-cairo --disable-libjava-multilib --enable-ssp --disable-libssp Thread model: posix gcc version 4.2.2 20071128 (prerelease) (4.2.2-3.1mdv2008.0) --- g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DVDR_USER=\vdr\ -DLIRC_DEVICE=\/dev/lircd\ -DRCU_DEVICE=\/dev/ttyS1\ -D_GNU_SOURCE -DVIDEODIR=\/video/video\ -DCONFDIR=\/video/video\ -DPLUGINDIR=\./PLUGINS/lib\ -DLOCDIR=\./locale\ -I/usr/include/freetype2 dvbsubtitle.c dvbsubtitle.c: In member function ‘int cDvbSubtitleConverter::Convert(const uchar*, int)’: dvbsubtitle.c:709: warning: format ‘%lld’ expects type ‘long long int’, but argument 3 has type ‘int64_t’ dvbsubtitle.c: In member function ‘virtual void cDvbSubtitleConverter::Action()’: dvbsubtitle.c:776: warning: format ‘%lld’ expects type ‘long long int’, but argument 3 has type ‘int64_t’ dvbsubtitle.c:776: warning: format ‘%lld’ expects type ‘long long int’, but argument 4 has type ‘int64_t’ dvbsubtitle.c:776: warning: format ‘%lld’ expects type ‘long long int’, but argument 5 has type ‘int64_t’ dvbsubtitle.c: In member function ‘int cDvbSubtitleConverter::ExtractSegment(const uchar*, int, int64_t)’: dvbsubtitle.c:845: warning: format ‘%lld’ expects type ‘long long int’, but argument 5 has type ‘int64_t’ g++ -g -O2 -Wall -Woverloaded-virtual -Wno-parentheses -c -DVDR_USER=\vdr\ -DLIRC_DEVICE=\/dev/lircd\ -DRCU_DEVICE=\/dev/ttyS1\ -D_GNU_SOURCE -DVIDEODIR=\/video/video\ -DCONFDIR=\/video/video\ -DPLUGINDIR=\./PLUGINS/lib\ -DLOCDIR=\./locale\ -I/usr/include/freetype2 remote.c remote.c: In member function ‘bool cRemote::Put(uint64_t, bool, bool)’: remote.c:124: warning: format ‘%016LX’ expects type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ remote.c:124: warning: format ‘%016LX’ expects type ‘long long unsigned int’, but argument 4 has type ‘uint64_t’ - Dave ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: can't set PID xxxx on device y
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) {
1051liveSubtitle = new cLiveSubtitle(TrackId-id);
1052AttachReceiver(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.c2008/02/16 13:52:11 1.153
+++ device.c2008/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
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR: can't set PID xxxx on device y
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) {
1051liveSubtitle = new cLiveSubtitle(TrackId-id);
1052AttachReceiver(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.c2008/02/16 13:52:11 1.153
+++ device.c2008/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.c2008/02/16 13:52:11 1.153
+++ device.c2008/02/17 15:55:06
@@ -1159,7 +1159,7 @@
bool cDevice::Transferring(void) const
{
- return dynamic_castcTransfer *(player) != NULL;
+ return ActualDevice() != PrimaryDevice();
}
bool cDevice::AttachPlayer(cPlayer *Player)
I hope this doesn't have any other side effects...
Klaus
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe don't start..
On Sunday, 17. Februaryta 2008 15:56:36 you wrote: Actually problem is bigger.. Gentoo xine-lib-1.1.10.1 don't install (or even compile) file xineplug_inp_xvdr.so... Fixing my own comment.. Of course not, because it's vdr-xineliboutput what SHOULD generate that file.. xine-lib-1.1.10 + vdr-xineliboutput-1.0.0_rc2_p20080120 = /usr/lib/xine/plugins/1.1.10/xineplug_inp_xvdr.so xine-lib-1.1.10.1 + vdr-xineliboutput-1.0.0_rc2_p20080120 =/usr/lib/xine/plugins/1.1.10.1/xineplug_inp_xvdr.so And that's the problem.. Rest of files are in /usr/lib/xine/plugins/1.1.10 -directory and that xineplug_inp_xvdr.so file is in /usr/lib/xine/plugins/1.1.10.1 -directory -- JJussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe don't start..
Hi! I finally find reason (it took whole day) for this problem.. I have to to downgrade xine-lib back to 1.1.8... Now everything works again.. On Saturday, 16. Februaryta 2008 13:05:54 JJussi wrote: Hi! Something went wrong when I update/re-emerge vdr.. Now vdr-sxfe don't start and giving reason: xine: cannot find input plugin for MRL [xvdr://127.0.0.1#nocache;demux:mpeg_block] I have re-emerge xine-lib vdr-xineliboutput and all other mpeg related packages.. No help. vdr system behind works fine, I can use vdr-sxfe from other computer to connect my vdr box.. Here is full startup log of vdr-sxfe: = vdr-sxfe 1.0.0rc2 (build with xine-lib 1.1.10, using xine-lib 1.1.10) Verbose mode VDR server not given, searching ... --- WARNING: MRL not given and server not found from local network. Trying to connect to default port on local host. --- load_plugins: skipping unreadable plugin directory /var/vdr/.xine/plugins. load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_yuv4mpeg2.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_ao_out_esd.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_flac.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_flac.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_vidix.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_vidix.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_inp_dvd.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_inp_file.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_ao_out_jack.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_xvmc.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_inp_http.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_avi.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_xshm.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_xshm.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_ao_out_oss.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_fb.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_mng.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_mpeg_elem.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_yuv_frames.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_mpeg_ts.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_decode_spudvb.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_xcbshm.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_sdl.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_real.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_inp_v4l.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_inp_v4l.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_decode_sputext.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_image.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_decode_spu.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_vo_out_aa.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_dmx_iff.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/xineplug_decode_rgb.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_visualizations.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_visualizations.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_visualizations.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_audio_filters.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_audio_filters.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_audio_filters.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_audio_filters.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_tvtime.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_switch.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin /usr/lib/xine/plugins/1.1.10/post/xineplug_post_planar.so found load_plugins: plugin
Re: [vdr] ERROR: can't set PID xxxx on device y
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.c2008/02/16 13:52:11 1.153
+++ device.c2008/02/17 15:55:06
@@ -1159,7 +1159,7 @@
bool cDevice::Transferring(void) const
{
- return dynamic_castcTransfer *(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.
--
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] dvb-ttpci: ARM crashed @ card 1
Rainer Zocholl wrote: 1.4.7), so having no signal on DVB-S is not un-typical for my system. 1.4.3 had the problem to restart vdr in such cases, beraking all other recording(*). This restart is not very noticable in the recording. Believe me, I do notice them. And they really only happen if a recording is totally stuck for at least one minute. I never had a restart due to EPG scan (at least not directly *), Me too (*) :-) I have to disable EPG scan because i have 3 Cards but only a single LNB! And, the Single-LNB-Patch did still not made its may into the release, so if EPG scan starts after an unpredictable time it will try to switch polarization, what fails and leads to no a signal condition witch is not detected to the EPGscan. So it again and again try to switch to that channel (see log in last mail) instead of skipping it. At least the logfile entries gives that impression. Question is, is that really the cause? Yesterday, I had my USB DVB-T connected, and forgot about it while a recording started on second DVB-S. First DVB-S was used for live TV, leaving just the DVB-T without antenna as free device. While 2 hours of recording, EPG scan permanently switched between three DVB-T transponders without receiving anything at all. No problems. IOW: During a VDR restart the crashed ARM was not detected and the black screeen state not healed. A DVB reload resets the ARM anyway, so the crash cannot exist across a restart. Maybe you suffer from strange tuning issues like me, and the 'blank screen' is just failure to tune anything? Have you tried experimenting with femon and signal levels? I have a similar 'blank screen' issue, but for me, the 'cure' is not a replay, but to force tuning the second DVB-S card to a channel. (Don't ask me why EPG scan on second DVB-S is not enough here.) After that, the tuner of the first card mysteriously reappears too. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DVB-T card on the move
Udo Richter wrote:
Theunis Potgieter wrote:
udev rules
Any good rules that could be used as a starting point?
Since there's no working solution yet that really satisfied me, I've
digged into this, trying to get automatic persistent numbering of
/dev/dvb/adapterX to work.
My first attempt however failed due to race problems since several dvb
sub-devices appear almost at the same time, and the persistent rules
cannot be updated without difficult synchronization. But at least I want
to post some rules that can be set up manually:
Check the output of udevinfo -a -n /dev/dvb/adapter0/frontend0. Under
'parent device' you'll find something like this:
KERNELS==:00:13.0
SUBSYSTEMS==pci
USB devices will look like this:
KERNELS==4-1
SUBSYSTEMS==usb
With this, you can set up a rule like this:
ACTION==add, SUBSYSTEM==dvb, SUBSYSTEMS==pci,
KERNELS==:00:13.0, \
PROGRAM=/bin/sh -c 'K=%k; echo dvb/adapter0/$${K#dvb*.}', \
NAME=%c
Create a file /etc/udev/rules.d/025_persistent-dvb.rules and put the
rule into it. Do this for _ALL_ your DVB devices, and give each device a
different number in the rule (eg. replace echo dvb/adapter0 in the rule
with other numbers).
This works, as long as no unknown devices appear that could end up using
some adapter number twice.
Cheers,
Udo
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] demuxing subtitles with projectx
Stefan Wagner wrote: Petri Helin [EMAIL PROTECTED] wrote: I noticed that Project-X is able to handle only subtitles within subID 0x20. I have a recording with subtitles with subIDs 0x20 and 0x21 and demuxing fails with command 248. If I restrict Project-X to subID 0x20, I am able to demux that recording too. Unfortunately this means that the second subtitle stream cannot be demuxed. Is this related to the TODO Klaus has marked for 0x21 in dvbsubtitle.c? can anyone provide dvb.matt from http://forum.dvbtechnics.info a little part of recording with 2 or more subtitle streams? so we can get a version of projectx thet supports more than one dvb-streams. I have opened a thread concerning this: http://forum.dvbtechnics.info/showthread.php?p=27527#post27527 -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.5.15
El Sun, 17 Feb 2008 15:46:42 +0100 Klaus Schmidinger [EMAIL PROTECTED] escribió: Note that you may need to switch back to an older version of your channels.conf file if you have already used version 1.5.14, because it introduced new parameters. In case there's no older version of channels.conf, is there some simple sed/awk/perl script to remove the extra fields, or is it not strictly necessary? Is it just a 's/M2O0S0//' when you only have dvb-s channels? Bye -- Luca ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe don't start..
On Sunday, 17. Februaryta 2008 00:51:45 Niko Mikkila wrote: On Sat, 16 Feb 2008 13:05:54 +0200 There seems to be no /usr/lib/xine/plugins/1.1.10/xineplug_inp_xvdr.so in your Xine plugin list. Is there such a file on your system (maybe it's in the wrong place, in some other directory)? If that file is missing or misplaced, the xineliboutput ebuild that you are using is probably broken. Actually problem is bigger.. Gentoo xine-lib-1.1.10.1 don't install (or even compile) file xineplug_inp_xvdr.so... -- JJussi ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] demuxing subtitles with projectx
Stefan Wagner wrote: Petri Helin [EMAIL PROTECTED] wrote: I noticed that Project-X is able to handle only subtitles within subID 0x20. I have a recording with subtitles with subIDs 0x20 and 0x21 and demuxing fails with command 248. If I restrict Project-X to subID 0x20, I am able to demux that recording too. Unfortunately this means that the second subtitle stream cannot be demuxed. Is this related to the TODO Klaus has marked for 0x21 in dvbsubtitle.c? can anyone provide dvb.matt from http://forum.dvbtechnics.info a little part of recording with 2 or more subtitle streams? so we can get a version of projectx thet supports more than one dvb-streams. The current cvs version works with at least two tracks, and according to dvb.matt it should support 16 separate tracks. It took only an hour from me opening the thread at the DVB technics forum till dvb.matt to add the support. Amazingly quick! -Petri ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe don't start..
Actually problem is bigger.. Gentoo xine-lib-1.1.10.1 don't install (or even compile) file xineplug_inp_xvdr.so... xine-lib-* will never install xineplug_inp_xvdr.so ;) this is the part of vdr-xineliboutput The problems comes only with/from the xine-lib-1.1.10.1 It creates/install the xine-* in /usr/lib/xine/plugins/1.1.10 not, depend for the Version, to /usr/lib/xine/plugins/1.1.10.1 But in the header file /usr/inlude/xine.h it shows the version 1.1.10.1. We detect this in the vdr-xineliboutput-*.ebuild an let install the xineplug_inp_*.so to the given dir by the headerfile. There is nothing wrong. Jussy, just skip the xine-lib-1.1.10.1 Version, use an older version, or i hope it will fixed by xine team, then the next version. -- Regards Gentoo Developer Joerg Bornkessel [EMAIL PROTECTED] ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe don't start..
On Sonntag, 17. Februar 2008, Joerg Bornkessel wrote: Actually problem is bigger.. Gentoo xine-lib-1.1.10.1 don't install (or even compile) file xineplug_inp_xvdr.so... xine-lib-* will never install xineplug_inp_xvdr.so ;) this is the part of vdr-xineliboutput The problems comes only with/from the xine-lib-1.1.10.1 It creates/install the xine-* in /usr/lib/xine/plugins/1.1.10 not, depend for the Version, to /usr/lib/xine/plugins/1.1.10.1 But in the header file /usr/inlude/xine.h it shows the version 1.1.10.1. We detect this in the vdr-xineliboutput-*.ebuild an let install the xineplug_inp_*.so to the given dir by the headerfile. There is nothing wrong. Jussy, just skip the xine-lib-1.1.10.1 Version, use an older version, or i hope it will fixed by xine team, then the next version. This is fixed in ebuild vdr-xineliboutput-1.0.0_rc2_p20080120-r1. Now we restrict the xine-lib version to 3 components. Regards Matthias -- Matthias Schwarzott (zzam) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe don't start..
On Sunday 17 February 2008, Matthias Schwarzott wrote: On Sonntag, 17. Februar 2008, Joerg Bornkessel wrote: We detect this in the vdr-xineliboutput-*.ebuild an let install the xineplug_inp_*.so to the given dir by the headerfile. There is nothing wrong. Jussy, just skip the xine-lib-1.1.10.1 Version, use an older version, or i hope it will fixed by xine team, then the next version. This is fixed in ebuild vdr-xineliboutput-1.0.0_rc2_p20080120-r1. Now we restrict the xine-lib version to 3 components. FWIW, I'm pretty certain that the only upstream supported way to retrieve the dir where to install xine plugins is to use xine-config --plugindir or pkg-config --variable=plugindir libxine. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] ATSC
Any chance we can get ATSC tunner card support with the next branch of vdr? In 1 year from today it will replace all analog TV broadcast in the US. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe don't start..
I demand that Ville Skyttä may or may not have written... On Sunday 17 February 2008, Matthias Schwarzott wrote: On Sonntag, 17. Februar 2008, Joerg Bornkessel wrote: We detect this in the vdr-xineliboutput-*.ebuild an let install the xineplug_inp_*.so to the given dir by the headerfile. There is nothing wrong. Yes there is – your detection method. Jussy, just skip the xine-lib-1.1.10.1 Version, use an older version, or i hope it will fixed by xine team, then the next version. Bad advice, unless the known potential for remote exploits (admittedly remote, but let's ignore that) isn't a problem for that particular installation. This is fixed in ebuild vdr-xineliboutput-1.0.0_rc2_p20080120-r1. Now we restrict the xine-lib version to 3 components. That'll be broken again by the next release (I've changed the naming), but there'll be a benefit: once the plugin is rebuilt, you'll be able to avoid rebuilding it unless you have need of some new ABI extension. Or at least that's the plan :-) (Incidentally, it was unrebuilt vdr-plugin-xineliboutput blocking xine-lib migration into Debian testing – needed for security fixes – which prompted this change...) FWIW, I'm pretty certain that the only upstream supported way to retrieve the dir where to install xine plugins is to use xine-config --plugindir or pkg-config --variable=plugindir libxine. They are, but you should not use pkg-config unless your plugin is not 1.1-compatible. -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | Let's keep the pound sterling Avoid commas, that are not necessary. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe don't start..
On Monday 18 February 2008, Darren Salt wrote: I demand that Ville Skyttä may or may not have written... FWIW, I'm pretty certain that the only upstream supported way to retrieve the dir where to install xine plugins is to use xine-config --plugindir or pkg-config --variable=plugindir libxine. They are, but you should not use pkg-config unless your plugin is not 1.1-compatible. Hmm... I'm having some problems parsing that, do you mean that only plugins that are 1.2-compatible but not 1.1-compatible should be using pkg-config? If not, could you rephrase? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
