VDR developer version 1.3.28 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.28.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.27-28.diff
The changes since version 1.3.27:
- Added a sleep in cDvbPlayer::Action() in case there is no data to send to the device, which avoids a busy loop on very fast machines (thanks to Martin Wache). - Modified the description of cDevice::Poll() to avoid misunderstandings. - Updated Croatian language texts (thanks to Drazen Dupor). - cDvbPlayer::Goto() now appends a Sequence End Code to get the image shown immediately with softdevices (thanks to Reinhard Nissl). - Reactivated cVideoRepacker in remux.c after some fixes (thanks to Reinhard Nissl). - Removed the fix for handling VPS timers, so that they only record if the event they are assigned to actually has the given VPS time. This has caused repeating VPS timers to stop recording prematurely. - Avoiding duplicate components in EPG events when reading epg.data or in the PUTE SVDRP command (thanks to Olaf Titz for reporting this one). - Added the command line options '--lirc', '--rcu' and '--no-kbd' to allow setting the remote control at runtime (based on a patch by Darren Salt). - Now checking whether timers or channels are currently being edited via the menu before making changes through SVDRP (thanks to Andreas Brugger for reporting a problem with this). - Files and directories are now created with rights according to the shell's umask settings (thanks to Andreas Brachold). - Fixed the cChannel copy constructor (thanks to Marcel Wiesweg for pointing out a problem with it). - Fixed an out-of-bounds memory access with audio language ids (thanks to Matthias Lenk for reporting, and Udo Richter for suggesting a fix). - Updated the Finnish OSD texts (thanks to Rolf Ahrenberg). - Added missing storing of the MenuScrollPage parameter (thanks to Frank Krömmelbein). - Added cRemux::SetTimeouts() for better use of cRemux in a single thread (thanks to Udo Richter for reporting a problem with this). - Modified cEITScanner::Process() so that it uses the primary device if it is replaying and is the only device that provides the given transponder, and that a forced EPG scan works even if EPG scan timeout is set to 0 (thanks to Bernhard Stegmaier for reporting a problem with this). - Fixed cDvbSpuBitmap::putPixel() (thanks to Reinhard Nissl). - Fixed setting system time to avoid time jumps in case of faulty data (thanks to Andreas Böttger). - Fixed a memory leak in the SVDRP command LSTE (thanks to Stefan Huelswitt).
The DVB driver I am currently using can be found at
ftp://ftp.cadsoft.de/vdr/Developer/linux-dvb.2004-12-26.tar.bz2
which is the CVS 'HEAD' version from 2004-12-26, made available as a complete archive for your convenience.
Of course, you can also use any newer driver version.
Have fun!
Klaus
Tomas Prybil wrote:
Klaus Schmidinger wrote:
VDR developer version 1.3.28 is now available at
Klaus, Will You make a call before planning the 1.4 release? I (and perhaps others) have some texts to catch up before the next stable release find it's way out the door.
Yes, I plan to do so.
Klaus
Klaus Schmidinger wrote:
VDR developer version 1.3.28 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.28.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.27-28.diff
The changes since version 1.3.27:
cPlugin::Popup is still on your todo list?
Bye
Luca Olivetti wrote:
Klaus Schmidinger wrote:
VDR developer version 1.3.28 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.28.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.3.27-28.diff
The changes since version 1.3.27:
cPlugin::Popup is still on your todo list?
Yes, but my day has only 24 hours... ;-)
Klaus
Klaus Schmidinger wrote:
VDR developer version 1.3.28 is now available at
Did you look at my patches in the list with subjects "[vdr] Re: Wishlist: running status" and "[vdr] [PATCH] Priority of transfer-mode should not be -1" on 2005-07-13 and 2005-06-29 or were you going to?
If there was something wrong with them, please reply to them.
Anssi Hannula wrote:
Klaus Schmidinger wrote:
VDR developer version 1.3.28 is now available at
Did you look at my patches in the list with subjects "[vdr] Re: Wishlist: running status" and "[vdr] [PATCH] Priority of transfer-mode should not be -1" on 2005-07-13 and 2005-06-29 or were you going to?
If there was something wrong with them, please reply to them.
Oh, sorry, didn't notice that you replied to one of those already.
Compiled, installed and it has already stopped...
This has the same defect as 1.3.27 on my machine. I am not overly happy with 1.3.26 so I will go back to 1.3.23 when I get back from holiday. Won't be able to test until September
Cheers
Tony
Le dimanche 07 août 2005 à 22:49 +0200, Klaus Schmidinger a écrit :
tony wrote:
Compiled, installed and it has already stopped...
This has the same defect as 1.3.27 on my machine. I am not overly happy with 1.3.26 so I will go back to 1.3.23 when I get back from holiday. Won't be able to test until September
Which "defect" is that?
It stops for a reason I have not yet found
Tony
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Which "defect" is that?
It stops for a reason I have not yet found
I think I am experiencing the same problem. When I activate the automatic EPG scan (i.e. timeout of 2 hours) my VDR suddenly stops responding to anything, I think around the time when it should be scaning. Neither remote, nor svdrp work then, and the watchdog does not restart it. It just sits there doing nothing. There is nothing suspicious in the logs. I have a FF-TechnoTrend DVB-S and a budget Airstar2 DVB-T.
I didn't really notice since I didn't use EPG Scan because of all those duplicate entries on Pro7, Sat1 etc. and reacivated it to test that nice w_epgfix-patch postet on vdrportal.de.
Malte Schröder wrote: ...
Which "defect" is that?
It stops for a reason I have not yet found
I think I am experiencing the same problem. When I activate the automatic EPG scan (i.e. timeout of 2 hours) my VDR suddenly stops responding to anything, I think around the time when it should be scaning. Neither remote, nor svdrp work then, and the watchdog does not restart it. It just sits there doing nothing. There is nothing suspicious in the logs. I have a FF-TechnoTrend DVB-S and a budget Airstar2 DVB-T.
I wonder what happens if VDR encounters an HDTV channel with a FF card during an EPG scan. Since new channels may get entered into channels.conf automatically, you may not even know that you have an HDTV channel in it.
Carsten.
On Monday 08 August 2005 10:19, Carsten Koch wrote:
Malte Schröder wrote: ...
Which "defect" is that?
It stops for a reason I have not yet found
I think I am experiencing the same problem. When I activate the automatic EPG scan (i.e. timeout of 2 hours) my VDR suddenly stops responding to anything, I think around the time when it should be scaning. Neither remote, nor svdrp work then, and the watchdog does not restart it. It just sits there doing nothing. There is nothing suspicious in the logs. I have a FF-TechnoTrend DVB-S and a budget Airstar2 DVB-T.
I wonder what happens if VDR encounters an HDTV channel with a FF card during an EPG scan. Since new channels may get entered into channels.conf automatically, you may not even know that you have an HDTV channel in it.
Should not be a problem, since only the receiving unit of the FF card is used. What causes troubles is the mpeg decoder chip which cannot handle the HDTV data rate (as far as I understand things).
--Stefan
Carsten.Koch@icem.com(Carsten Koch) 08.08.05 10:19
Malte Schröder wrote: ...
Which "defect" is that?
It stops for a reason I have not yet found
I think I am experiencing the same problem. When I activate the automatic EPG scan (i.e. timeout of 2 hours) my VDR suddenly stops responding to anything, I think around the time when it should be scaning. Neither remote, nor svdrp work then, and the watchdog does not restart it. It just sits there doing nothing. There is nothing suspicious in the logs. I have a FF-TechnoTrend DVB-S and a budget Airstar2 DVB-T.
~~
I wonder what happens if VDR encounters an HDTV channel with a FF card during an EPG scan.
I think that's known? A standard full feature card will die after fewseconds, and VDR(?) will hang in a loop trying to talk to the dead card. Or was that fixed?
Since new channels may get entered into channels.conf automatically, you may not even know that you have an HDTV channel in it.
Aren't HDTV marked with an impossible CAM tag?
Rainer Zocholl wrote:
Carsten.Koch@icem.com(Carsten Koch) 08.08.05 10:19
Malte Schröder wrote: ...
Which "defect" is that?
It stops for a reason I have not yet found
I think I am experiencing the same problem. When I activate the automatic EPG scan (i.e. timeout of 2 hours) my VDR suddenly stops responding to anything, I think around the time when it should be scaning. Neither remote, nor svdrp work then, and the watchdog does not restart it. It just sits there doing nothing. There is nothing suspicious in the logs. I have a FF-TechnoTrend DVB-S and a budget Airstar2 DVB-T.
~~
I wonder what happens if VDR encounters an HDTV channel with a FF card during an EPG scan.
I think that's known? A standard full feature card will die after fewseconds, and VDR(?) will hang in a loop trying to talk to the dead card. Or was that fixed?
It's only a problem if an HDTV channel is tuned to for live viewing. The EPG scan just tunes to the transponder and doesn't turn on live viewing. Therefore the pure EPG scan shouldn't be a problem.
Since new channels may get entered into channels.conf automatically, you may not even know that you have an HDTV channel in it.
Aren't HDTV marked with an impossible CAM tag?
I've marked those that I knew of, but things may have changed. So far I don't know how to identify an HDTV channel from the SI data.
Klaus
Am 07.08.2005 um 17:07 schrieb Klaus Schmidinger:
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:
Aug 9 20:12:00 linvdr user.info vdr[1451]: timer 1 (2 2012-2108 'Familie Hitler') start Aug 9 20:12:00 linvdr user.debug vdr[1451]: Title: 'Familie Hitler' Subtitle: 'Im Schatten des Diktators' Aug 9 20:12:00 linvdr user.info vdr[1451]: record /video0/ Familie_Hitler/2005-08-09.20.12.50.99.rec Aug 9 20:12:00 linvdr user.debug vdr[1451]: creating directory / video0/Familie_Hitler Aug 9 20:12:00 linvdr user.debug vdr[1451]: creating directory / video0/Familie_Hitler/2005-08-09.20.12.50.99.rec Aug 9 20:12:00 linvdr user.debug vdr[1451]: recording to '/video0/ Familie_Hitler/2005-08-09.20.12.50.99.rec/001.vdr' Aug 9 20:12:01 linvdr user.debug vdr[1806]: file writer thread started (pid=1806, tid=65548) Aug 9 20:12:01 linvdr user.debug vdr[1807]: recording thread started (pid=1807, tid=66573) Aug 9 20:12:01 linvdr user.debug vdr[1808]: receiver on device 1 thread started (pid=1808, tid=67598) Aug 9 20:12:01 linvdr user.debug vdr[1809]: TS buffer on device 1 thread started (pid=1809, tid=68623) Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: skipped 10 bytes to sync on next picture Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: skipped 16 bytes to sync on next picture Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: skipped 16 bytes to sync on next picture Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: skipped 48 bytes while syncing on next picture Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: skipped 1990 bytes while syncing on next picture Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: skipped 491 bytes while syncing on next picture Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: skipped 4 bytes to sync on next picture Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: skipped 1648 bytes while syncing on next picture Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: skipped 390 bytes while syncing on next picture Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: skipped 1412 bytes while syncing on next picture Aug 9 20:12:01 linvdr user.err vdr[1807]: cVideoRepacker: skipped 4 bytes to sync on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 10 bytes to sync on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 1142 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 896 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 1663 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 4 bytes to sync on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 1930 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 108 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 2039 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 39 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 4 bytes to sync on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 16 bytes to sync on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: found system start code: stream seems to be scrambled or not demultiplexed Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 1321 bytes while syncing on next picture Aug 9 20:12:02 linvdr user.err vdr[1807]: cVideoRepacker: skipped 492 bytes while syncing on next picture 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 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...
Ciao, Dominique
Lauri Tischler wrote:
Klaus Schmidinger wrote:
So far I don't know how to identify an HDTV channel from the SI data.
ETSI defines in Component descriptor, Stream_content 0x01 Component_type 0x09..0x10 as 'high definition video'. Isn't that HDTV ?
Yes, but in all my epg.data there's not a single entry with a type value of 09..10. So either I don't have any HDTV channel in my channels.conf, or they don't broadcast HD at all, or they just don't provide (proper) EIT data.
Does anybody have any such entry in their epg.data file?
Klaus