Hi!
Before reinventing the wheel - is there any tool that can cut
VDR's TS recordings outside of VDR? (Something like hlcut for
VDR 1.6 recordings).
Thx,
Tobias
Hello all,
I have recently purchased a TechnoTrend 1500 DVB-T PCI card with CI
daughter board. I also have an official CAM and Smartcard for our local
DVB-T service. The DVB-T in the air broadcasts 4 FtA channels and the
rest encrypted. I can scan and find all the channels properly. Also
watching FtA channels works without a problem. EPG I also receive for
all channels in question. The CAM menu lists my cam properly (Conax
4.00e) and all information seems to be proper. I activated my smartcard
…
[View More]via the phone this morning so that sh ould also not cause any problem.
dmesg lists my cam as successfully initialized:
Dec 16 16:19:11 erin kernel: [ 2771.999892] dvb_ca adapter 0: DVB CAM
detected and initialised successfully
I also have a ivtv based device in the box using the pvrinput plugin,
but that shouldn't cause this? From the log I find the following after
changing from channel 42 (FtA) to 64 (Scrambled) and back.
Dec 16 17:58:55 erin vdr: [2756] switching to channel 42
Dec 16 17:58:55 erin vdr: [2884] transfer thread ended (pid=2756, tid=2884)
Dec 16 17:58:55 erin vdr: [2756] buffer stats: 40232 (1%) used
Dec 16 17:58:55 erin vdr: [2888] transfer thread started (pid=2756,
tid=2888)
Dec 16 17:58:55 erin vdr: [2887] osdteletext-receiver thread ended
(pid=2756, tid=2887)
Dec 16 17:58:55 erin vdr: [2756] buffer stats: 0 (0%) used
Dec 16 17:58:55 erin vdr: [2889] osdteletext-receiver thread started
(pid=2756, tid=2889)
Dec 16 17:58:56 erin vdr: [2888] [xine..put] Detected video size 704x576
Dec 16 17:58:56 erin vdr: [2888] setting audio track to 1 (0)
Dec 16 17:58:59 erin vdr: [2756] switching to channel 64
Dec 16 17:58:59 erin vdr: [2888] transfer thread ended (pid=2756, tid=2888)
Dec 16 17:58:59 erin vdr: [2756] buffer stats: 75388 (3%) used
Dec 16 17:58:59 erin vdr: [2889] osdteletext-receiver thread ended
(pid=2756, tid=2889)
Dec 16 17:58:59 erin vdr: [2890] transfer thread started (pid=2756,
tid=2890)
Dec 16 17:59:00 erin vdr: [2886] TS buffer on device 1 thread ended
(pid=2756, tid=2886)
Dec 16 17:59:00 erin vdr: [2885] buffer stats: 78960 (3%) used
Dec 16 17:59:00 erin vdr: [2885] receiver on device 1 thread ended
(pid=2756, tid=2885)
Dec 16 17:59:00 erin vdr: [2891] receiver on device 1 thread started
(pid=2756, tid=2891)
Dec 16 17:59:00 erin vdr: [2756] buffer stats: 0 (0%) used
Dec 16 17:59:00 erin vdr: [2756] creating directory
/var/cache/osdteletext/T-8720-2213-32
Dec 16 17:59:00 erin vdr: [2893] TS buffer on device 1 thread started
(pid=2756, tid=2893)
Dec 16 17:59:00 erin vdr: [2892] osdteletext-receiver thread started
(pid=2756, tid=2892)
Dec 16 17:59:01 erin vdr: [2756] retuning due to modification of channel 64
Dec 16 17:59:01 erin vdr: [2756] switching to channel 64
Dec 16 17:59:01 erin vdr: [2890] transfer thread ended (pid=2756, tid=2890)
Dec 16 17:59:01 erin vdr: [2756] buffer stats: 39480 (1%) used
Dec 16 17:59:01 erin vdr: [2894] transfer thread started (pid=2756,
tid=2894)
Dec 16 17:59:04 erin vdr: [2756] switching to channel 42
any idea why the scrambled stream isn't being decoded?
00:0a.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH DVB T-1500
Flags: bus master, medium devsel, latency 32, IRQ 18
Memory at fc123000 (32-bit, non-prefetchable) [size=512]
Kernel driver in use: budget_ci dvb
Kernel modules: budget-ci
Module Size Used by
snd_pcm_oss 26176 0
snd_mixer_oss 10616 1 snd_pcm_oss
radeon 620116 2
wm8775 2416 1
tuner 14720 2
cx25840 23108 1
lirc_imon 19540 1
tda1004x 11484 1
ivtv 114436 1
ttm 37408 1 radeon
budget_ci 15716 16
drm_kms_helper 17912 1 radeon
rc_hauppauge_new 984 0
lirc_dev 8312 3 lirc_imon
budget_core 5580 1 budget_ci
saa7146 10336 2 budget_ci,budget_core
cx2341x 8636 1 ivtv
cfbcopyarea 2776 1 radeon
imon 17728 0
cfbimgblt 1800 1 radeon
tveeprom 12204 1 ivtv
cfbfillrect 2664 1 radeon
ttpci_eeprom 1288 1 budget_core
crw-rw----+ 1 root video 212, 6 Dec 16 15:33 ca0
crw-rw----+ 1 root video 212, 4 Dec 16 15:33 demux0
crw-rw----+ 1 root video 212, 5 Dec 16 15:33 dvr0
crw-rw----+ 1 root video 212, 3 Dec 16 15:33 frontend0
crw-rw----+ 1 root video 212, 7 Dec 16 15:33 net0
Thanks,
Oliver
[View Less]
VDR developer version 1.7.16 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.16.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.15-1.7.16.diff
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.7.15:
- Updated the Italian OSD texts …
[View More](thanks to Diego Pierotto).
- Added missing Dtypes for ATSC (thanks to Alex Lasnier).
- Updated the Portuguese language texts (thanks to Cristiano A. Silva).
- Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
- Fixed the array size of Atypes in cPatFilter::Process() (thanks to
Rolf Ahrenberg).
- Added locking to the cCutter functions to avoid a crash in case CutRecording()
is called from a plugin (reported by Andreas Mair).
- Fixed DDS detection for HD resolution subtitles (thanks to Reinhard Nissl).
- Fixed following symbolic links in RemoveFileOrDir().
- Added support for languages that are written right-to-left (based on a patch
from Osama Alrawab). See INSTALL for information on how to turn this on.
- Added Arabian language texts (thanks to Osama Alrawab).
Have fun!
Klaus
[View Less]
Hi everyone,
I am using vdr version 1.7.16 and I have discovered some A/V Sync problems
after jumping to another mark or jumping with the yellow/green button.
Is that an already-known-problem?
Looking at Henning Heinhold’s patch [1] he changed the includes to the C++ headers instead of the C headers. At least Wikipedia says [2], that the C headers are deprecated.
C++ provides this functionality in the header cstdarg; the C header, though permitted, is deprecated in C++.
Is it desirable to change the includes in all files? If yes, is there a tool which would accomplish this, since after the substitution a reordering is needed?
[1] http://cgit.openembedded.org/cgit.cgi/…
[View More]openembedded/tree/recipes/vdr/files/c…
[2] https://secure.wikimedia.org/wikipedia/en/wiki/Stdarg.h
Signed-off-by: Paul Menzel <paulepanter(a)users.sourceforge.net>
---
tools.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/tools.c b/tools.c
index 3ce12ec..9a400a8 100644
--- a/tools.c
+++ b/tools.c
@@ -8,9 +8,12 @@
*/
#include "tools.h"
-#include <ctype.h>
+#include <cctype>
+#include <cerrno>
+#include <cstdarg>
+#include <cstdlib>
+#include <ctime>
#include <dirent.h>
-#include <errno.h>
extern "C" {
#ifdef boolean
#define HAVE_BOOLEAN
@@ -18,11 +21,8 @@ extern "C" {
#include <jpeglib.h>
#undef boolean
}
-#include <stdarg.h>
-#include <stdlib.h>
#include <sys/time.h>
#include <sys/vfs.h>
-#include <time.h>
#include <unistd.h>
#include <utime.h>
#include "i18n.h"
--
1.7.2.3
[View Less]
The gettext version I use automatically adds a Language field to the
headers of the po-Files. It would be nice to have this field there in
the first place, so here's a small patch that adds it.
Tobias
On Tue, 7 Dec 2010, Ville Skyttä wrote:
> Don't stop reading there. I don't know about forbidden, but they do write
> that the value "is" something else, a bit below the above quoted part:
I didn't! :)
> * In this PO file field, but not in locale names, ‘ll_CC’ combinations
> denoting a language's main dialect are abbreviated as ‘ll’. For example, ‘de’
> is equivalent to ‘de_DE’ (German as spoken in Germany), and ‘pt’ to ‘pt_PT’
> (Portuguese as spoken in Portugal) in this …
[View More]context.
> * In this PO file field, suffixes like ‘.encoding’ are not used.
> * In this PO file field, variant designators that are not relevant to message
> translation, such as ‘@euro’, are not used.
>
> So, if your locale name is ‘de_DE.UTF-8’, the language specification in PO
> files is just ‘de’."
So, "de" is a synonym for "de_DE" and both definitions are as correct as
they can be according to my interpretation.
> But leaving out the country only applies to _the_ (there can be only one I
> gather) primary dialect of a language. So both zh_CN and zh_TW cannot be the
> primary dialect; dunno if there's such a thing for Chinese in the first place.
> If you look at my patch carefully, you'll see that for zh_CN.po the value of
> the Language field is zh_CN.
And you could use here the plain "zh" as it defaults to "zh_CH" -
according to my quick Google searchs.
> I did not invent any of these values myself - I just first fixed the Language-
> Team fields so that gettext itself understands them, and then ran the files
> through gettext, and copied/included in my patch what gettext itself had
> added.
> I think following what gettext's docs say/recommend and what it actually does
> itself is the best approach.
In that case those plain language codes are enough. I was just thinking
about new translation that might come in future using subdialects.
Translators usually uses the existing ones as a starting point and might
not remember to update these fields correctly.
BR,
--
rofa
[View Less]
On Mon, 6 Dec 2010, Ville Skyttä wrote:
> On Saturday 04 December 2010, Tobias Grimm wrote:
>> The gettext version I use automatically adds a Language field to the
>> headers of the po-Files. It would be nice to have this field there in
>> the first place, so here's a small patch that adds it.
>
> The Language fields for the main dialect of a language should not have
> _COUNTRY (i.e. Language: de, not Language: de_DE etc). More info:
> http://www.gnu.org/…
[View More]software/gettext/manual/gettext.html#Header-Entry
"Fill in the language code of the language. This can be in ONE of three
forms: ‘ll’, ‘ll_CC’, ‘ll_CC@variant’"
Where is the country code forbidden exactly? The core VDR doesn't have
same language for different areas, but i.e. the femon does: "zh_CN" and
"zh_TW". If I would use the plain "zh" for both of these, the "zh_TW.po"
file would be interpreted as "zh_CN" and that really doesn't sound
rigth. With VDR's current language files this doesn't make any
difference, but I prefer Tobias' patch with your language team
modifications a bit more future proof.
BR,
--
rofa
[View Less]
On Mon, 6 Dec 2010, Mario Schulz wrote:
> Am 05.12.2010 23:33, schrieb Klaus Schmidinger:
>> What would that be necessary for?
I'd like to prevent EIT scans on IPTV devices.
> In its default behaviour VDR will add transponders and channels to the
> channels.conf, as a result these will be searched and probably result in
> a match and a timer entry, even for uninteresting or undecodable channels.
The following patch might expose the necessary API for plugins to create
…
[View More]white and/or blacklists for EIT scanning on certain devices/channels.
BR,
--
rofa
diff -Nru vdr-1.7.16-vanilla/device.c vdr-1.7.16-eitscan/device.c
--- vdr-1.7.16-vanilla/device.c 2010-09-19 19:42:08.000000000 +0300
+++ vdr-1.7.16-eitscan/device.c 2010-12-06 17:36:33.000000000 +0200
@@ -56,6 +56,11 @@
return true;
}
+bool cDeviceHook::DeviceProvidesEITScan(const cDevice *Device, const cChannel *Channel) const
+{
+ return true;
+}
+
// --- cDevice ---------------------------------------------------------------
// The default priority for non-primary devices:
@@ -594,6 +599,17 @@
return true;
}
+bool cDevice::DeviceHooksProvidesEITScan(const cChannel *Channel) const
+{
+ cDeviceHook *Hook = deviceHooks.First();
+ while (Hook) {
+ if (!Hook->DeviceProvidesEITScan(this, Channel))
+ return false;
+ Hook = deviceHooks.Next(Hook);
+ }
+ return true;
+}
+
bool cDevice::ProvidesTransponder(const cChannel *Channel) const
{
return false;
diff -Nru vdr-1.7.16-vanilla/device.h vdr-1.7.16-eitscan/device.h
--- vdr-1.7.16-vanilla/device.h 2010-09-19 19:42:08.000000000 +0300
+++ vdr-1.7.16-eitscan/device.h 2010-12-06 17:41:18.000000000 +0200
@@ -96,6 +96,8 @@
///< program ends.
virtual bool DeviceProvidesTransponder(const cDevice *Device, const cChannel *Channel) const;
///< Returns true if the given Device can provide the given Channel's transponder.
+ virtual bool DeviceProvidesEITScan(const cDevice *Device, const cChannel *Channel) const;
+ ///< Returns true if the given Device can scan EIT on the given Channel's transponder.
};
/// The cDevice class is the base from which actual devices can be derived.
@@ -204,6 +206,8 @@
static cList<cDeviceHook> deviceHooks;
protected:
bool DeviceHooksProvidesTransponder(const cChannel *Channel) const;
+public:
+ bool DeviceHooksProvidesEITScan(const cChannel *Channel) const;
// SPU facilities
diff -Nru vdr-1.7.16-vanilla/eitscan.c vdr-1.7.16-eitscan/eitscan.c
--- vdr-1.7.16-vanilla/eitscan.c 2010-09-19 19:42:08.000000000 +0300
+++ vdr-1.7.16-eitscan/eitscan.c 2010-12-06 17:38:40.000000000 +0200
@@ -146,7 +146,7 @@
if (Device) {
for (cScanData *ScanData = scanList->First(); ScanData; ScanData = scanList->Next(ScanData)) {
const cChannel *Channel = ScanData->GetChannel();
- if (Channel) {
+ if (Channel && Device->DeviceHooksProvidesEITScan(Channel)) {
if (!Channel->Ca() || Channel->Ca() == Device->DeviceNumber() + 1 || Channel->Ca() >= CA_ENCRYPTED_MIN) {
if (Device->ProvidesTransponder(Channel)) {
if (!Device->Receiving()) {
[View Less]