Re: [vdr] Restoring recordings from image

[vdr user #7]

Hi,
15 years ago I've accidently deleted an XFS drive full of recordings.
And even in those (*.vdr) days foremost wasn't the most successful tool
in order to recover recordings.

What I've done:

    1. I've made an (dd-) image
    2. I used a modified version of genindex to scan the image

The result where thousands of small video files (the number depends on
the degree of fragmentation of your drive).
This was working fairly well, but most of the recordings were not worth
recovering because I had to solve the puzzle of concatinating dozens of
files (out of the thousands) in the correct order.

But if it helps you here is my patch:
diff -ur genindex-0.1.3.orig/file.c genindex-0.1.3/file.c
--- genindex-0.1.3.orig/file.c    2006-06-01 22:09:10.0 +0200
+++ genindex-0.1.3/file.c    2008-11-19 14:59:52.0 +0100
@@ -181,16 +181,20 @@

 cFileName::~cFileName()
 {
+  printf(">close %s<\n", filename);
   close(fd);
 }

-int cFileName::Open(void)
+int cFileName::Open(off64_t xxx = 0)
 {
   close(fd); fd=-1;
   cString filename;
   if(input) filename=input;
   else filename=cString::sprintf(FILENAME,fileno);
   fd=open64(filename,O_RDONLY);
+  if (xxx > 0) {
+    lseek64(fd,xxx,SEEK_SET);
+  }
   if(fd>=0) {
 struct stat64 st;
 if(fstat64(fd,&st)==0) {
diff -ur genindex-0.1.3.orig/file.h genindex-0.1.3/file.h
--- genindex-0.1.3.orig/file.h    2006-06-01 17:12:25.0 +0200
+++ genindex-0.1.3/file.h    2008-11-19 15:01:15.0 +0100
@@ -54,12 +54,13 @@
 public:
   cFileName(const char *Input, bool LargeOK);
   ~cFileName();
-  int Open(void);
+  int Open(off64_t);
   int NextFile(void);
   int OpenWrite(void);
   int NextWriteFile(void);
   int Skip(int nr, int off);
   int FileNumber(void) { return fileno; }
+  void SetFileNumber(int i) {fileno = i;}
   long long FileSize(void) { return size; }
   };

Only in genindex-0.1.3: file.o
Only in genindex-0.1.3: genindex
diff -ur genindex-0.1.3.orig/genindex.c genindex-0.1.3/genindex.c
--- genindex-0.1.3.orig/genindex.c    2006-06-02 15:44:31.0 +0200
+++ genindex-0.1.3/genindex.c    2008-11-19 15:00:58.0 +0100
@@ -41,6 +41,8 @@
 char *destdir=0;
 char *input=0;
 int splitsize=2000;
+long long startat=0;
+int firstnum=1;
 bool rewrite=false;
 bool quiet=false;

@@ -61,6 +63,7 @@
   //
   unsigned int sSize;
   int splitOffset;
+  long long startOffset;
   bool pstart;
   //
   unsigned char buff[KILOBYTE(256)];
@@ -77,7 +80,7 @@
 public:
   cGenIndex(void);
   ~cGenIndex();
-  void Work(void);
+  void Work(off64_t);
   void Skip(int type);
   };

@@ -86,6 +89,7 @@
   index=new cIndex(destdir);
   fileName=new cFileName(input,input && rewrite);
   writeName=new cFileName(destdir,true);
+  writeName->SetFileNumber(firstnum);

   if(rewrite) {
 SetDefaultRule(prSkip);
@@ -124,7 +128,7 @@
   return replayFile>=0;
 }

-void cGenIndex::Work(void)
+void cGenIndex::Work(off64_t startat = 0)
 {
   eof=error=pstart=false;
   memset(fileSize,0,sizeof(fileSize));
@@ -137,14 +141,16 @@
   }
 }

-  replayFile=fileName->Open();
+  readOffset=startat;
+
+  replayFile=fileName->Open(readOffset);
   readNo=fileName->FileNumber();
   fileSize[readNo]=fileName->FileSize();
-  readOffset=0;

   fileNo=rewrite ? 1 : readNo;
   fileOffset=0;
   splitOffset=splitsize*MEGABYTE(1);
+  startOffset=startat*MEGABYTE(1);
   sSize=0;

   if(replayFile>=0) {
@@ -236,7 +242,7 @@
 }

   if(rewrite) {
-    if(scan && fileOffset>=splitOffset && (pstart || sSize)) {
+    if(scan && (fileOffset>=splitOffset || nextFile) && (pstart ||
sSize)) {
   if(sSize+len>sizeof(store)) {
 printf("Oops! Packet buffer overflow\n");
 error=true;
@@ -246,7 +252,7 @@
   sSize+=len;
   }
 else {
-  if(fileOffset>=splitOffset && sSize && ftype==I_FRAME) {
+  if((fileOffset>=splitOffset || nextFile) && sSize &&
ftype==I_FRAME) {
 writeFile=writeName->NextWriteFile();
 if(writeFile<0) {
   printf("Failed to open output file(s)\n");
@@ -254,6 +260,7 @@
   return -1;
   }
 packetNo=fileNo=writeName->FileNumber();
+    nextFile=false;
 packetOffset=0;
 fileOffset=sSize;
 }
@@ -343,6 +350,8 @@
 {
   static struct option long_options[] = {
   { "rewrite",  no_argument,   NULL, 'r' },
+  { "startat",  required_argument, NULL, 'a' },
+  { "firstnum", required_argument, NULL, 'f' },
   { "quiet",    no_argument,   NULL, 'q' },
   { "dest", required_argument, NULL, 'd' },
   { "split",    required_argument, NULL, 's' },
@@ -353,8 +362,14 @@

   int s=0, str[MAX_STR];
   int c;
- while((c=getopt_long(argc,argv,"rqd:s:i:",long_options,NULL))!=-1) {
+ while((c=getopt_long(argc,argv,"rqd:s:i:a:f:",long_options,NULL))!=-1) {
 switch (c) {
+  case 'a':
+    startat=atoll(optarg);
+    break;
+  case 'f':
+    firstnum=atoi(optarg);
+    break;
   case 'r':
 rewrite=true;
 break;
@@

Re: [vdr] vdr Digest, Vol 161, Issue 4

[VDR User]

> you can have a look at the nvidia gt 1030 cards. there are lowprofile and 
> fanless versions,
> but pay attention to card size.
> and you may need to install correct drivers manually.
> but, half the price then an intel nuc with luck.

If all you need is a video card, that's a decent option. If you're
looking for a whole new system, you'll easily spend more than the cost
of a NUC.

> i'm considering this myself, too, instead of this buggy intel hd grahpics... 
> (well, nvidia isn't better, i know...)

What bug(s) are you referring to? Intel/VAAPI has been very smooth &
stable here. Not a single problem and no bugs that I've experienced.
From what I can tell the people talking about buggy drivers don't
actually use Intel HD, they just seem to be repeating what someone
else said, or maybe they have a problem outside of VDR/Kodi/HTPC/media
playback.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Advice for best hardware and plugins to play MKV files and receive 4K channels

[VDR User]

> >xineliboutput and VDPAU so I assume what you actually mean by mkv is
> >being able to play back HD or greater content using VDPAU for decoding
> >and xineliboutput to get the decoded frames to your tv.
> Correct, my 4K mkv files are using H.265 codecs, HD files are using H.264.

Since dumping Nvidia I haven't kept up with what their current cards
capabilities are so I can't advise on an Nvidia card that does
HEVC/h265. My NUC handles it great though! ;)

> I didn't understand which player/plugin you advise in VDR.
> - MPlayer was very good but no longer works...
> - Media Player in Xineliboutput is convenient but little buggy under VDPAU...

I originally used mplayer, then mplayer2, and lastly mpv player. The
vdr-mplayer plugin + mpv player has worked great. All you have to do
to switch from mpv is just change your mplayer.sh (or whatever you
call your player script) from using the mplayer bin to mpv bin.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Advice for best hardware and plugins to play MKV files and receive 4K channels

[VDR User]

> I plan to upgrade my VDR box, with these two important features :
> - reading mkv files => I am using xineliboutput and vdpau.

MKV is just a container for data streams and support is wide-spread.
Any half-decent player supports mkv. It's also unrelated to
xineliboutput and VDPAU so I assume what you actually mean by mkv is
being able to play back HD or greater content using VDPAU for decoding
and xineliboutput to get the decoded frames to your tv. VDPAU is EOL.
Nvidia currently has NVDEC but I can't speak to how well it's
supported since I dumped VDPAU for VAAPI a while back.

> - receiving 4K channels => for HD, I am using old PCI/PCIE motherboard + 
> TBS6928 (with CI).
>
> Could you share best hardware cpu/video/card,motherboard/..., & best 
> plugin/driver/... you advice at the moment?

When I switched from VDPAU to VAAPI I retired my old hardware and just
spent about $120 on an Intel NUC, and couldn't be happier. I'll never
bother with video cards again for htpc/media playing boxes. And also
non-usb tuners. Low power/low space is my theme now so my days of
building pc's for this purpose are over. You might want to look at
other options unless you actually want a pc tower.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR version 2.4.0 released

[VDR User]

Thanks Klaus & all contributors to VDR!

On Sun, Apr 15, 2018 at 3:44 AM, Karim AFIFI  wrote:
> Hi Klaus,
>
> Many thanks for this new release, and all the job around it !
>
> Regards.
> Karim
>
> -Message d'origine-
> De : vdr [mailto:vdr-boun...@linuxtv.org] De la part de Klaus Schmidinger
> Envoyé : dimanche 15 avril 2018 11:37
> À : VDR mailing list
> Objet : [vdr] [ANNOUNCE] VDR version 2.4.0 released
>
> VDR version 2.4.0 is now available at
>
>ftp://ftp.tvdr.de/vdr/vdr-2.4.0.tar.bz2
>
> A 'diff' against the previous version is available at
>
>ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.9-2.4.0.diff
>
> MD5 checksums:
>
> 12c6a3abeadfa915fcfe736bb047a3ab  vdr-2.4.0.tar.bz2
> 6d98c2d619e82f3d4503146602fccde7  vdr-2.3.9-2.4.0.diff
>
> A summary of all the major changes since the last stable version 2.2.0 can be 
> found at
>
>   http://www.tvdr.de/changelog.htm
>
> When updating from an earlier version of VDR please make sure you read the 
> INSTALL
> and MANUAL files that come with the VDR source _before_ doing so!
> Please make sure you have backup copies of all your configuration files,
> and verify carefully that your timers will be set to the correct channels
> after switching to this new version.
>
> Thanks to the many people who have contributed in the making, testing and
> debugging of this new version of VDR, and also to all users who just
> enjoy VDR!
>
> Please also visit the VDR homepage at
>
>   http://www.tvdr.de
>
> and VDR's facebook page at
>
>   https://www.facebook.com/VideoDiskRecorder
>
> Have fun!
>
> Klaus
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Channels getting deleted on new scan

[VDR User]

Definitely true! We have an obsession with trying to be `different` or
non-standard. For some reason people and companies don't feel
"special" enough otherwise.

On Sun, Mar 11, 2018 at 2:31 PM, Timothy D. Lenz  wrote:
> Standards??? what's that? Only thing around here that is standard is to be
> proprietary
>
>
> On 3/11/2018 2:19 PM, Klaus Schmidinger wrote:
>>
>> On 11.03.2018 22:10, Timothy D. Lenz wrote:
>>>
>>> It turns out that both stations are owned by the same company. I have
>>> sent KGUN9 a second email about the conflict and reported it to the FCC as
>>> interference because they interfering with each other. Looking at this site:
>>> https://www.linuxtv.org/vdrwiki/index.php/Syntax_of_channels.conf
>>>
>>> I found this near the end:
>>>
>>> "RID
>>> Radio ID. Typical 0. Can be used to differentiate between channels having
>>> the same SID, NID and TID."
>>
>>
>> Introducing the RID was a pretty ugly workaround.
>> I suggest not to use it and rather try and find somebody at the
>> broadcaster who knows his stuff ;-).
>>
>> My guess is they simply copy/pasted the configuration
>> for these channels and didn't bother adhering to standards.
>>
>> Klaus
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR not cleaning .del directories

[VDR User]

> My video directory is nfs-mounted to a raspberry pi running another vdr.  In
> my case, I have not changed the configuration in any way, but despite of
> daily usage, this has not reoccurred.  So either some other patch fixed the
> problem for me, or this is some extremely rarely happening race condition
> type thing.

Just for reference, my recordings directory is also an nfs share but I
don't recall ever experiencing this issue.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[VDR User]

> It still does lock up.
>
> I think it is really softhddevice problem, as the lockup only happens
> if actually viewing the channel.. My VDR box is always on, and usually
> I just turn off the projector and leave VDR running. Perhaps I need to
> change my habits and actually suspend softhddevice when not really
> watching it.

Ideally you should be able to run VDR 24/7 without issue. That's what
I do and have no intention of changing the habit. Unfortunately
softhddevice is no longer actively developed by its' author but there
are still some coders in the VDR community who have helped keep it
updated. It's possible they may be able to help fix this bug if enough
information can be provided. In my cause the frozen/defunct VDR seems
to occur if I lose signal for some unknown length of time, and doesn't
seem related to audio. Fortunately it's the only problem I have and it
doesn't happen daily. It would however be great if it were fixed -
hopefully we'll get to that point.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[VDR User]

>> I made this change few hours ago, but I'm still waiting for the
>> problem to appear.. Obviously it now is working 100%. :)

Same here.

> Does "working 100%" mean that youre not getting any of these error
> messages any more? Not even once?

I'm not getting them right now either but it only means the conditions
that cause it haven't occurred yet. It will though - it always does
sooner or later unfortunately.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] projects.vdr-develper.org down

[VDR User]

Thanks for the update. Explains why I haven't been able to connect
just now. Hopefully the repos are ok!

On Sun, Jun 18, 2017 at 6:20 AM, Tobi  wrote:
> Hi!
>
> Right now the server seems to have some trouble. I'm working on this, but
> it might take a while.
>
> bye,
>
> Tobias
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] : fdisk preventing quick recordings

[VDR User]

http://linuxscripter.blogspot.com/2012/03/how-to-disable-fsck-on-reboot.html

On Mon, May 8, 2017 at 6:41 AM, g.bruno  wrote:
> Hallo,
>
> quite often I encounter the following problem:
> when I want to record a broadcast spontaneously of which the beginning is e.
> g. 10 minutes ahead, Ubuntu (Xubuntu 14.04) sometimes starts fdisk for my
> recordings-partition which is about 900 MB large. This takes such a long
> time, about 20 minutes, that I miss the beginning of the film I want to
> record.
> At first I get the message " /dev/sda5 was mounted 20 times without being
> checked. Check forced ..." or so.
> Unfortunatedly, there is no warning that fisk is to be run the next time I
> boot.
> In /etc/fstab I marked "dump 0" and "pass 2" as it is recommanded.
> Is it possible to have fsck running AFTER recording before shutdown when 19
> mountings have been done? Or have I to set "pass" on 0. I'm a little bit
> scared of this because it means that I could loose data resp. recordings.
> By the way, on my desktop-computer I set pass to 2 as well, but never fsck
> runs when I boot even more then 20 times. Here the large (1 TB)
> /home/-partition is ext4-filesystem. May this make the difference?
>
> Thanks for your answers.
>
> Greetings
> gbruno
>
>
>
>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] To: vdr@linuxtv.org, [ANNOUNCE] VDR developer version 2.3.3

[VDR User]

Thank you Klaus (and contributors), for your hard work in bringing the
VDR community this newest version! Compiling now :)



On Tue, Mar 28, 2017 at 2:10 AM, Klaus Schmidinger
 wrote:
> VDR developer version 2.3.3 is now available at
>
>   ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.3.tar.bz2
>
> A 'diff' against the previous version is available at
>
>   ftp://ftp.tvdr.de/vdr/Developer/vdr-2.3.2-2.3.3.diff
>
> MD5 checksums:
>
> 73182b570bcf5a67ab56f7734e479631  vdr-2.3.3.tar.bz2
> 112c2057dbd7e86c31f8227f61cfd2a6  vdr-2.3.2-2.3.3.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 2.3.2:
>
> - Added 'S3W ABS-3A' to sources.conf (thanks to Frank Richter).
> - Fixed a possible deadlock in the recordings handler thread.
> - Updated the Russian OSD texts (thanks to Andrey Pridvorov).
> - Added a missing dependency to the Makefile to avoid error messages in the
>   clean-plugins target (thanks to Tobias Grimm).
> - The channel/CAM relations (i.e. the information which CAM can decrypt a
> given
>   channel) are now stored in the file 'cam.data' in the cache directory
> (suggested
>   by Dietmar Spingler). This speeds up switching to encrypted channels after
>   newly starting VDR, in case there is more than one CAM in the system.
> - Fixed a flaw in handling timeouts for encrypted channels.
> - The mechanism of trying different CAMs when switching to an encrypted
> channel is
>   now only triggered if there acually is more than one CAM in the system.
> - Fixed updating the elapsed/remaining time in the progress display during
> fast
>   forward/rewind.
> - Changed 'unsigned' to 'signed' in some places to avoid trouble with abs()
> in
>   gcc6+ (reported by Derek Kelly).
> - CAMs that can handle multiple devices at the same time can now indicate
> this
>   by creating the first cCamSlot as usual, and every other cCamSlot by
> giving
>   it the first one as its "MasterSlot". To VDR this means that when
> searching
>   for a CAM that can decrypt a particular channel, it only needs to ask the
>   master CAM slot whether it is suitable for decrypting, and can skip all
> the
>   other slots belonging to the same master. This can greatly speed up
> channel
>   switching on systems with more than one CAM (that can handle multiple
> devices).
> - The LCARS skin now displays the master CAM's number when a device is tuned
> to
>   an encrypted channel.
> - The Setup/CAM menu now only displays master CAMs.
> - Fixed setting the local machine's SVDRP host name (was overwritten if
> setup.conf
>   contained an empty string).
> - PIDs can now be added to and deleted from a cReceiver while it is attached
> to
>   a cDevice, without having to detach it first and re-attach it afterwards.
> - Implemented support for MTD ("Multi Transponder Decryption"). This allows
> a CAM
>   that is capable of decrypting more than one channel ("Multi Channel
> Decryption")
>   to decrypt channels from different transponders. See the remarks in mtd.h
> on
>   what a derived cCamSlot class needs to do in order to activate MTD (thanks
> to
>   Jasmin Jessich for writing the ddci2 plugin and for valuable input and
> help
>   with testing and debugging).
> - The function cRingBufferLinear::Clear() can now be called safely from the
>   reading thread, without additional locking.
> - Now stopping any ongoing recordings before stopping the plugins, to avoid
>   a crash when stopping VDR while recording.
>
> Have fun!
>
> Klaus
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[VDR User]

Andreas/fnu:
I didn't realize it varied that much from NA/SA/JP vs. EU but I guess
so! Out of curiosity, whats the ballpark average bitrate of your
non-sports 1080p content?

For those using device bonding, per Klaus's latest post it will live
to see another day in the VDR core. I did, I think (my translator is
horrible), see someone asking @ vdr-portal if it could be put into a
plugin. If so, does that make sense for this kind of feature?

-Derek

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[VDR User]

Andreas:
As I said, no "magic" or "luck" is needed. Apparently you've never
heard of bandstacking. In the case of DVB-S, it's where one side is
carried in 950-1450Mhz and the other is carried in 1650-2150Mhz - full
circular lnb on ..one..single..cable,..no..magic. Bandstacking doesn't
use voltage switching, instead it simply operates at 18v. Power is
supplied either by the tuner or by a powered switch (if present). It's
not new and very commonly used here in NA/SA so whatever looking into
this subject you did, you didn't look very hard. It's reasonable that
you may live in some old crappy apartment with a horrible setup where
you truly are without options. You'll have a hard time finding such a
building here however. For that matter, most apartments have no
problem with tenants setting up dishes of their own with few
restrictions.

fnu:
I'm talking about reality - equipment that is common here and I have
used myself. Using bandstacking, yes, one coax is all you need for an
entire satellite. The only requirement is that the coax is rated up to
2150Mhz (ie: RG6). Bandstacking needs to be supports at the lnb (about
$5-7) and the switch (from around $20-$80, depending). This equipment
is common and has been used for many years here. That being the case,
I would be very surprised if the same wasn't true for Europeans...
Apparently though it's not since you guys are referring to this as
"magic" and not `reality`.

-Derek

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[VDR User]

> I would like to know which magic switch behind a single cable receiving only 
> one polarization/band allows feeding multiple tuners with independent 
> signals. ;-)

There is no "magic", you probably should read up on switches I guess.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[VDR User]

> pretty simple, there are users who cannot change their SAT infrastructure 
> easily. The reasons are varied, e.g. they are tenants and not allowed to 
> change it by the owners, they own it and cannot change it due to the rules of 
> commonhold association or the own it and the construction of apartment/house 
> doesn't allow changes etc.

Are you saying people are not allowed to put a switch at the point
where the cable plugins into their dvb device? It would be no
different that putting an ethernet switch on your ethernet line. You
don't need to alter anything aside of instead of the cable going into
your dvb card, it goes into your switch. 100% internal, 100% your own
hardware.

-Derek

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[VDR User]

> they do in vdr-portal.de ... as I already do remember a bunch of users still 
> using that function and the reasons why, so no what-if-scenarios.

Not sure why you didn't mention that earlier but aside of that it
still doesn't answer this part: "I'd like to know why they don't just
use a switch. Simple, cheap, easy, and no complex code required."

One of the main purposes of a switch is to feed multiple tuners from a
single cable so it's not like device bonding is a vital feature. The
pros don't seem to outweigh the cons but if enough people actually use
it it sounds like Klaus will take it into consideration.

-Derek

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [POLL] Is anybody actually using "device bonding" (aka "LNB sharing)?

[VDR User]

There's no point in worrying about what-if scenarios, actual real
world usage is what matters. Klaus is giving those who use device
bonding the chance to speak up now. If there's very little-to-no
interest in it, it's gone. Unless I've misunderstood the intention
here. If there rally is someone out there who only has 1 cable and for
some reason can't run more, I'd like to know why they don't just use a
switch. Simple, cheap, easy, and no complex code required.

-Derek

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR locking up

[VDR User]

Hi and thanks for your reply. Currently the kernel is 4.8.4 stable,
gp8psk kernel driver, vdr-2.2.0. However, this problem has been going
on for quite a while - I'm just now getting around to asking about it.
The drivers I use haven't been changed in years so I'm not sure that's
where the root cause is. It's interesting that you've experienced it
as well with a completely different card/drivers. I wonder if
downgrading your drivers really had any affect of it the conditions
which cause the problem to surface just haven't happened yet.
Hopefully others will chime in as well and we can get to the bottom of
it. It may be an infrequent problem but it has a nasty result!

-Derek

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] VDR locking up

[VDR User]

Occasionally my signal drops out (haven't looked into it yet), and it
causes VDR to completely freeze and become defunct/zombie. That locks
up the drivers and the only way to resolve it is by rebooting. No core
file gets created. Does anyone know how to prevent the lock-up in the
first place? Could it be some kind of leak from the looping (see log
clip below)?

Here's a clip of the log when it happens. You can see how the log gets
filled with the same repeating lines until it crashes.

2016.Oct.28|12:08:55 video: slow down video, duping frame
2016.Oct.28|12:08:55 video: decoder buffer empty, duping frame
(5656/167423) 7 v-buf
2016.Oct.28|12:09:29 video: slow down video, duping frame
2016.Oct.28|12:16:09 [1297] [softhddev]Clear:
2016.Oct.28|12:16:09 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:09 audio/alsa: using device 'default'
2016.Oct.28|12:16:09 audio/alsa: start delay 336ms
2016.Oct.28|12:16:09 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:10 audio/alsa: start delay 336ms
2016.Oct.28|12:16:10 [1297] [softhddev]Clear:
2016.Oct.28|12:16:10 audio/alsa: using device 'default'
2016.Oct.28|12:16:10 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:11 audio/alsa: using device 'default'
2016.Oct.28|12:16:11 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:11 audio/alsa: start delay 336ms
2016.Oct.28|12:16:11 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:12 audio/alsa: start delay 336ms
2016.Oct.28|12:16:12 [1297] [softhddev]Clear:
2016.Oct.28|12:16:12 audio/alsa: using device 'default'
2016.Oct.28|12:16:12 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:13 audio/alsa: start delay 336ms
2016.Oct.28|12:16:13 [1297] [softhddev]Clear:
2016.Oct.28|12:16:13 audio/alsa: using device 'default'
2016.Oct.28|12:16:13 [1297] ERROR: TS packet not accepted in Transfer Mode
2016.Oct.28|12:16:13 audio

Re: [vdr] Skinflatplus plugin Channel Logo Names

[VDR User]

> I am using *.png, but what I meant was, what are the naming requirements,
> for the files, so that the skin selects the correct logo for the current
> channel tuned?

Filenames should match the longname (if present), or the shortname. For example:

BBC HD, BBCHD:.. it would be "bbc hd.png".
BBCHD:.. it would be "bbchd.png".

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Skinflatplus plugin Channel Logo Names

[VDR User]

png

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Help debugging a segfault cause

[VDR User]

Hi,

I recently had to update packages on a Debian testing box. Afterwards
I recompiled fresh VDR + plugins. Now when I start VDR, it crashes
with a segfault. I know the versions of everything are fine as I'm
running the same versions on other VDR boxes.

Does this look like a linkage problem? Any ideas/help is appreciated!

=
Thread 1 (Thread 0xb71df700 (LWP 25684)):
#0 0x in ?? ()
#1 0xb771b13e in futex_wake (private=0, processes_to_wake=2147483647,
futex_word=0xb64e5604) at
../sysdeps/unix/sysv/linux/futex-internal.h:231
#2 __pthread_once_slow (once_control=0xb64e5604,
init_routine=0xb6463ea0) at pthread_once.c:127
#3 0xb6464c95 in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
#4 0xb642e96b in ?? () from /usr/lib/i386-linux-gnu/libGL.so.1
#5 0xb77bf341 in call_init (l=0x888b5b0, argc=argc@entry=1,
argv=argv@entry=0xbfba6da4, env=0xbfba6dac) at dl-init.c:58
#6 0xb77bf4ae in call_init (env=0xbfba6dac, argv=0xbfba6da4, argc=1,
l=) at dl-init.c:30
#7 _dl_init (main_map=main_map@entry=0x888a9e0, argc=1,
argv=0xbfba6da4, env=0xbfba6dac) at dl-init.c:120
#8 0xb77c3767 in dl_open_worker (a=0xbfba58bc) at dl-open.c:575
#9 0xb77bf224 in _dl_catch_error (objname=objname@entry=0xbfba58b4,
errstring=errstring@entry=0xbfba58b8,
mallocedp=mallocedp@entry=0xbfba58b3, operate=0xb77c3390
, args=0xbfba58bc) at dl-error.c:187
#10 0xb77c2f22 in _dl_open (file=0x8889168
"/usr/local/dvb/vdr.source/vdr-2.2.0/PLUGINS/lib/libvdr-softhddevice.so.2.2.0",
mode=-2147483646, caller_dlopen=0x811d099 ,
nsid=, argc=1, argv=0xbfba6da4, env=0xbfba6dac) at
dl-open.c:660
#11 0xb7708bf5 in dlopen_doit (a=0xbfba5a70) at dlopen.c:66
#12 0xb77bf224 in _dl_catch_error (objname=0xc84,
errstring=0xc88, mallocedp=0xc80, operate=0xb7708b80
, args=0xbfba5a70) at dl-error.c:187 #13 0xb770930d in
_dlerror_run (operate=operate@entry=0xb7708b80 ,
args=args@entry=0xbfba5a70) at dlerror.c:163
#14 0xb7708c9e in __dlopen (file=0x8889168
"/usr/local/dvb/vdr.source/vdr-2.2.0/PLUGINS/lib/libvdr-softhddevice.so.2.2.0",
mode=2) at dlopen.c:87
#15 0x0811d099 in cDll::Load (this=0xef8, Log=) at
plugin.c:223
#16 0x0811df01 in cPluginManager::LoadPlugins (this=0xbfba6c50,
Log=true) at plugin.c:351
#17 0x080a3820 in main (argc=, argv=) at vdr.c:732
(gdb)

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] broken recordings

[VDR User]

>>> Sorry for interrupting with stupid questions.. Would'nt a NAS do a better
>>> job in this case?
>>
>> I would guess no since the nic on a raspberry pi uses the usb bus.
>
> Uhh.. That sounds like a bad combination... So the raspberry seems to be
> best for streaming just in one direction...

The rpi wasn't designed to be a htpc/dvr, but that hasn't stopped
people from trying to use it as one. Honestly, I bought one with that
intention myself but it just didn't work well enough for my needs so
it collects dust in the closet.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] broken recordings

[VDR User]

> Sorry for interrupting with stupid questions.. Would'nt a NAS do a better
> job in this case?

I would guess no since the nic on a raspberry pi uses the usb bus.

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] broken recordings

[VDR User]

It really does sound like you're saturating the usb bus. Are you sure
you're comparing against real world performance and not
technical/theoretical?

On Mon, Aug 8, 2016 at 11:30 AM, Matthias Bodenbinder
 wrote:
> Hello Christoph,
>
> based on your feedback I made another test. The USB HD performance seems to 
> be ok (see my other reply). But anyways I made a test with recording directly 
> to the Flash SD card. And that works pretty well. 15 min without issue.
>
> So it looks like it is indeed an issue with USB on the Raspberry PI 2. Any 
> idea how to solve that?
>
> Matthias
>
>
> Am 08.08.2016 um 11:10 schrieb C.Scheeder:
>> Hi,
>> it meuns your system is not able to process all the data received in time.
>> where do you write your recordings?
>> I guess its a usb-harddisk connected to your raspi, correct?
>> It's probably just to slow to write all the data vdr throws at it.
>> Or your usb-bus is saturated with all the data flowing in from your receiver 
>> and back out to the harddisk.
>> Christoph
>>
>> Am 07.08.2016 um 16:34 schrieb Matthias Bodenbinder:
>>> One more hint to the problem.
>>>
>>> Another test with recording Arte HD gives the following output in user.log:
>>>
>>> Aug  7 16:31:14 raspberry vdr: [28148] timer 1 (5 1503-1655 'Galaxis 
>>> Milchstraße') set to event Son 07.08.2016 15:05-16:45 (VPS: 07.08. 15:05) 
>>> 'Galaxis Milchstraße'
>>> Aug  7 16:31:19 raspberry vdr: [6438] i/o throttle activated, count = 1 
>>> (tid=6438)
>>> Aug  7 16:31:22 raspberry vdr: [6438] buffer usage: 70% (tid=6448)
>>> Aug  7 16:31:24 raspberry vdr: [6438] buffer usage: 80% (tid=6448)
>>> Aug  7 16:31:26 raspberry vdr: [6438] buffer usage: 90% (tid=6448)
>>> Aug  7 16:31:29 raspberry vdr: [6438] buffer usage: 100% (tid=6448)
>>> Aug  7 16:31:29 raspberry vdr: [6438] ERROR: 1 ring buffer overflow (1 
>>> bytes dropped)
>>> Aug  7 16:31:35 raspberry vdr: [6438] ERROR: 26189 ring buffer overflows 
>>> (4923532 bytes dropped)
>>> Aug  7 16:31:41 raspberry vdr: [6438] ERROR: 32283 ring buffer overflows 
>>> (6069204 bytes dropped)
>>> Aug  7 16:31:47 raspberry vdr: [6438] ERROR: 36593 ring buffer overflows 
>>> (6879484 bytes dropped)
>>>
>>>
>>> What does that mean?
>>>
>>> Matthias
>>>
>>> ___
>>> vdr mailing list
>>> vdr@linuxtv.org
>>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>>
>>
>>
>> ___
>> vdr mailing list
>> vdr@linuxtv.org
>> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Error in compile softhddevice

[VDR User]

The official softhddevice git is outdated for most people it seems.
You'll have to patch it for newer ffmpeg support.

http://anonscm.debian.org/cgit/pkg-vdr-dvb/vdr-plugin-softhddevice.git/tree/debian/patches/ffmpeg3-pixelformat.patch
http://anonscm.debian.org/cgit/pkg-vdr-dvb/vdr-plugin-softhddevice.git/tree/debian/patches/ffmpeg3-pixfmt.patch
http://anonscm.debian.org/cgit/pkg-vdr-dvb/vdr-plugin-softhddevice.git/tree/debian/patches/ffmpeg3_buffer.patch

On Fri, Jul 1, 2016 at 8:54 PM, Behrooz Ramezani
 wrote:
> Hello evryone
> I give this error when i compile softhddevice
> [behrooz@Lenovo-G500 softhddevice-0.6.0]$ make
> g++ -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -g
> -fvar-tracking-assignments -O3 -fPIC -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64
> -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -I/usr/include/alsa
> -DPLUGIN_NAME_I18N='"softhddevice"' -D_GNU_SOURCE  -DAV_INFO
> -DAV_INFO_TIME=3000 -DUSE_PIP -DUSE_ALSA -DUSE_OSS
> -DUSE_VDPAU -DUSE_VAAPI -DUSE_SCREENSAVER -DUSE_SWRESAMPLE   -g -W -Wall
> -Wextra -Winit-self -Werror=overloaded-virtual   -c -o softhddevice.o
> softhddevice.cpp
> In file included from softhddevice.cpp:46:0:
> video.h:63:13: error: use of enum 'PixelFormat' without previous declaration
>  extern enum PixelFormat Video_get_format(VideoHwDecoder *, AVCodecContext
> *,
>  ^~~
> video.h:64:16: error: use of enum 'PixelFormat' without previous declaration
>  const enum PixelFormat *);
> ^~~
> softhddevice.cpp: In member function 'virtual void cSoftOsd::Flush()':
> softhddevice.cpp:480:31: error: invalid conversion from 'cPixmap*' to
> 'cPixmapMemory*' [-fpermissive]
>  while ((pm = RenderPixmaps())) {
>   ~^~
> softhddevice.cpp: At global scope:
> softhddevice.cpp:2046:18: error:   by 'virtual void
> cSoftHdDevice::TrickSpeed(int)' [-Werror=overloaded-virtual]
>  virtual void TrickSpeed(int);
>   ^~
> cc1plus: some warnings being treated as errors
> make: *** [: softhddevice.o] Error 1
>
> I using Arch linux
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] "TS packets to determine frame type"

[VDR User]

Yup, I see your reasoning behind it. Only one thing though...
Transcoding is not going to give you improved quality regarding of
what encoder and settings you use. Size can be reduced which is a plus
but there's degradation with every trip a stream makes through an
encoder. Encoding always has and always will be a one-way street in
terms of quality.

On Wed, Jun 15, 2016 at 11:52 AM, Richard F  wrote:
> For my specific situation logic goes like this, FWIW:
>
> - The script started when I was working on the other side of the world a 
> couple of years ago, and was downloading TV regularly. I started by using 
> what others had done and improved/modified for my circumstances.  Reducing 
> the recorded size by ~60% into MKV's made this possible. It seemed a 
> relatively short stretch to modify it to save local space, with improved 
> quality as an option as well. It became a seamless reality, and then under 
> real-world testing, a few non-fatal issues came up.
>
> - 4TB disks are USD 150 - the ones I'd buy where I am at least.
>
> - Having lost at least 2 new enterprise class disks in quick succession a few 
> years ago with some valuable data and recordings not backed-up, I wouldn't 
> consider not using a RAID or other reliable storage technique.  Hence a RAID 
> upgrade would be USD 450 equivalent.
>
> - I'm at 93% on my 4TB RAID and by reducing this to maybe 60-70% I can see 
> out the disks' lives, perhaps another 2 yrs by which time, based on current 
> trends I expect rotating disks will no longer be required because TCO 
> (considering the need to RAID them + power use over lifetime which is not 
> insignificant) means SSD's will probably be cost effective.  So the USD 450 
> on a new RAID right now would be largely wasted, I plan to wait and go direct 
> to low power non-RAID SSD, which is the holy grail (financially and 
> environmentally).
>
> Make a bit more sense now?
>
> Richard
>
>
> - On 14 Jun, 2016, at 15:20, VDR User user@gmail.com wrote:
>
>> Curious why you're bothering to do this now when 4tb harddrives are
>> always on sale in the $90 range. 6+ years ago it made more sense but
>> now it seems like too little too late. Just wondering
>>
>> On Tue, Jun 14, 2016 at 6:21 AM, Richard F  
>> wrote:
>>> I will do.
>>>
>>> Now I'm testing it on a range of recordings, I'm seeing a few issues
>>> with ffmpeg/libraries, which I'm addressing with workarounds or reports
>>> to the ffmpeg devs.
>>>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] "TS packets to determine frame type"

[VDR User]

Curious why you're bothering to do this now when 4tb harddrives are
always on sale in the $90 range. 6+ years ago it made more sense but
now it seems like too little too late. Just wondering

On Tue, Jun 14, 2016 at 6:21 AM, Richard F  wrote:
> I will do.
>
> Now I'm testing it on a range of recordings, I'm seeing a few issues
> with ffmpeg/libraries, which I'm addressing with workarounds or reports
> to the ffmpeg devs.
>
> The aim is to convert all old VDR1.6, and current VDR2.x recordings,
> including radio, as well automatic transcoding after a recording is
> made, retaining 100% perceived quality / stream content which is
> possible with careful codec/parameter selection.  Perhaps a plugin one
> day to save as x264/aac if the stream isn't already in that format, as
> the space saving can be as much as 50% (e.g. last night an SD recording
> reduced from 995M to 497M).
>
> Subtitle streams seem to be the largest issue currently - probably not
> so well tested.
>
> Richard
>
>
> On 9/06/2016 19:52, Stephan Loescher wrote:
>> Hi Richard,
>>
>> Would you share your script, after finishing?
>> Would be very interesting!
>>
>> Greetings,
>> Stephan.
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Media (.mkv) player on Raspberry Pi2 VDR client

[VDR User]

Gerald,

You freak out because I suggested an easier solution to yours, and
then call me a troll for correcting you on your own nonsense. I hope
you don't think you're fooling anyone with that fake b.s. Take your
temper tantrums somewhere else, or get lost.

==

Nicolas,

Sorry your thread got polluted with this garbage. Gerald has a history
of lashing out at people who disagree with him or have any criticism
about yavdr. It's pathetic but hopefully in all the nonsense you've
found a solution that suits you.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Media (.mkv) player on Raspberry Pi2 VDR client

[VDR User]

>> He's not asking about HDMI-CEC so this is irrelevant. Additionally,
>> HDMI-CEC support can be very limited on the device end so just because
>> a device technically supports it, that doesn't automatically mean you
>> can do what you want using HDMI-CEC. And plenty of people like me
>> already use multi-device remotes so we don't have to bother with
>> configuring HDMI-CEC at all.
> I can't see why it is a problem to mention other features he would get
> with another solution.

I didn't say it was a problem, I said it's not what he's asking for.
And since you put it that way, not everybody likes a salesman who
tries to "upgrade" or "upsell" the customer to a bunch of stuff they
didn't ask for in the first place. Why is it so difficult for you to
accept there's an simple answer to his simple question that doesn't
involve Kodi.

> On an RPi? With hardware support? I don't believe that.

I didn't say anything about hardware support.

>> I'm only stating the obvious, that Kodi is absolutely unnecessary to
>> give the OP what he's asking for. There is no denying this. And, he
>> can decide if he wants to bother adding Kodi to his setup just to play
>> mkvs, or if something less extreme makes more sense.
>
> If you let him really decide you shouldn't make solutions bad without
> any proof, only
> because you don't like them.

I haven't said any solution to his problem is bad and I have said I
don't like anything. Once again I have to point out that Kodi is
unnecessary to play mkvs. It's idiotic to even question that fact but
if you really need "proof" then go ahead and install the vdr-mplayer
plugin and prove it to yourself. If you don't want to do that then you
can install the vdr-play plugin as an alternative.

> I asked you already before to explain what makes OpenELEC more
> complicated, you
> didn't answer.

Yes, I have answered that question. Feel free to refer to my previous
posts and perhaps pay better attention to what's being said.

> The only thing that is really obvious that you have no idea what you are
> talking about.

Do you have any idea how completely foolish that sounds?

> As the founder of yaVDR I have some experiences how complicated a vdr
> setup can be.
> As a contributor to OpenELEC I know how simple the setup in OE currently is.

If I'm supposed to be impressed by that, it's not working. I've been a
VDR user for nearly 15 years and have never relied on anyones
pre-compiled packages. I've automated practically every aspect from OS
install to fully working VDR, including auto-configuring things
outside of VDR. So what, who cares? This isn't about how big my
johnson is or how tiny yours seems to be. This started out with a guy
asking a simple question - how can I play mkvs in VDR? If you want to
act butthurt because someone pointed out that all it takes is the
vdr-mplayer or vdr-play plugin then start a new thread about it. I
doubt he posted to the ML in hopes of seeing someone get all sensitive
over Kodi and start acting like its' honor must be defended at all
cost.. It's really starting to seem teenage girl'ish so maybe you
should give it a rest.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Media (.mkv) player on Raspberry Pi2 VDR client

[VDR User]

> No, absolutely not. The setup of OpenELEC is much less complicated and
> dependencies are no problem.
> The vdr-addon and the vnsi-addon gets installed by some clicks on the remote
> and a first channel scan
> needs only some clicks more.

It's always no problem until something breaks..

> The raspberry pi has superior HDMI-CEC support that is used automatically by
> Kodi, so in most cases
> there is even no need for an IR receiver and an extra remote. The remote of
> the TV is just enough. That
> simplifies the setup even more.

He's not asking about HDMI-CEC so this is irrelevant. Additionally,
HDMI-CEC support can be very limited on the device end so just because
a device technically supports it, that doesn't automatically mean you
can do what you want using HDMI-CEC. And plenty of people like me
already use multi-device remotes so we don't have to bother with
configuring HDMI-CEC at all.

> The topic is about playing .mkv. That is just a container. What about the
> used codecs? In the upcoming OpenELEC
> 0.7 there will even be support of H265 on the RPi. The Kodi GUI has no
> problems with playing 3D content.
> Is this working with your solution too?

I use the vdr-mplayer plugin with mpv-player (rather than mplayer).
Yes, it works great. I've already played plenty of h265 content. I
don't have a 3D capable card or tv but that works fine too. Very
simple, very lightweight. Adding Kodi is adding a whole other layer of
software and it's completely unnecessary. He's asking for something
very simple, the solution should also be the same. There's no point in
bloating his system and adding a whole other layer of software on top
of VDR that he never asked for in the first place. You don't have to
defend Kodi, I'm not trashing it. Kodi is nice when it's not broken.
I'm only stating the obvious, that Kodi is absolutely unnecessary to
give the OP what he's asking for. There is no denying this. And, he
can decide if he wants to bother adding Kodi to his setup just to play
mkvs, or if something less extreme makes more sense.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Media (.mkv) player on Raspberry Pi2 VDR client

[VDR User]

>> You don't need to bother with Kodi (unless you actually want to use
>> it). VDR + the mplayer plugin work perfectly fine. There's no point in
>> unnecessarily complicating a persons setup if that's not what they
>> want.
> I know nothing in OpenELEC that is complicating a persons setup, what do
> you have in mind?
> At least his current setup is complicated enough so that he has no idea
> what to do next.

He has no idea what to do next because he lacks information, not
because his setup is complicated. And, any time you bundle additional
software along with all of the dependencies that come with it, it's
just more to maintain and more that can break. What sense does that
make when all he wants to do is play mkvs? Kodi is completely
unnecessary, surely you agree.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Media (.mkv) player on Raspberry Pi2 VDR client

[VDR User]

You don't need to bother with Kodi (unless you actually want to use
it). VDR + the mplayer plugin work perfectly fine. There's no point in
unnecessarily complicating a persons setup if that's not what they
want.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PLUGIN] pulsecontrol - configure Pulseaudio via vdr's OSD

[VDR User]

This sounds like a very useful plugin. Thanks for your work!

On Sat, Dec 26, 2015 at 3:30 AM, Lars Hanisch  wrote:
> Hi all,
>
>  While releasing yaVDR 0.6[1] (blog post will come after the holidays) I 
> wrote a little plugin called pulsecontrol:
>
>  Announce:
>  
> http://www.vdr-portal.de/board16-video-disk-recorder/board55-vdr-plugins/127846-
>
>  Source:
>  https://github.com/flensrocker/vdr-plugin-pulsecontrol
>
>  If you use Pulseaudio for audio output, you can change some settings of it 
> via the vdr's OSD like moving a sink-input
> between sinks or selecting different card profiles. You can also change the 
> passthrough settings of a card.
>
>  If you want to select a specific card profile or sink on vdr's startup, you 
> can place a file called "startup.script" in
> the plugin's config directory. The plugin will run it while starting. For now 
> only two commands are supported:
> set-card-profile and move-sink-input. But more will come if needed.
>
>  If there are multiple files with the script-extension in this directory you 
> can select and run them via OSD.
>
>  Hopefully someone will find it useful. :)
>
>  A hint for pulseaudio-newbies: if you want to use AC3 etc. passthrough over 
> hdmi with softhddevice, select the profile
> "output:hdmi-stereo", not "output:hdmi-surround". And don't forget to 
> activate passthrough in softhddevice. It's a bit
> confusing to use the stereo-profile, but it's the right one. With Kodi you 
> have to select it as well.
>
>  Hint 2: On my Asrock HT330 pulseaudio always forgets the selected profile. 
> You can modify /etc/pulse/system.pa (or
> default.pa) for selecting it or the plugin's startup.script. With "svdrpsend 
> plug pulsecontrol list-cards" you can
> determine the right card and profile name.
>
>  Bug reports and feature wishes are welcome.
>
> Lars.
>
>
> [1] 
> http://www.vdr-portal.de/board16-video-disk-recorder/board99-distributionen/board96-yavdr/127885-announce-yavdr-0-6-0/
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] projects.vdr-developer.org maintenance

[VDR User]

Thanks for all your work! The site is a great resource for the VDR community!

On Sat, Dec 12, 2015 at 5:29 PM, Tobi  wrote:
> Everything should be up and running and shiny new now!
>
> I've upgraded the server OS from Debian/Squeeze to Debian/Jessie and
> Redmine from 1.2.1 to 3.2.0.
>
> Besides this, the site now uses a Letsencrypt SSL certificate and any
> non-SSL requests get redirected to https://.
>
> Please let me know, if you encounter any problems.
>
> Most likely, I need to do some minor tweaks during the next days, so you
> might encounter short outages.
>
> BR,
>
> Tobias
>
>
>
>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr on arch linux, and on debian wiki

[VDR User]

My first introduction to VDR was on Debian. I've only ever used VDR
with Debian and I can say the NA community is primarily Debian,
followed by Ubuntu. I think the lack of interest is with a wiki, not
with Debian users.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] watching DVDs

[VDR User]

I don't watch dvds but I do use mpv-player via the vdr-mplayer to
playback various media. You could try that.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] from xineliboutput to ... perhaps softhdddevice?

[VDR User]

Actually cedarX hw decoding was another question I forgot in my
previous post. I've read that it's working in linux but I didn't know
if any output devices supported it (yet)?. Was hoping softhddevice
does, or would if I sent Johns an A20. :)



On Fri, Apr 17, 2015 at 11:17 AM, Cedric de Wijs
 wrote:
>
>
> On 4/17/2015 2:13 PM, VDR User wrote:
>>
>> For those of you using Raspberry Pi or Allwinner boards, how is osd
>> performance? If the osd is fast & smooth, I'm interested in building
>> a couple vdr setups like those (maybe Raspberry Pi 2. Rpi is just too
>> slow). Any degrade in performance is a deal-breaker for me.
>>
>> Thanks
>>
> Hi,
>
> OSD performance is not an issue on an allwinnerA20, with one exception. I
> have 640GB SD recordings. The first time after VDR startup, opening the list
> with recordings is a bit slow (about a second). This is on a olimex A20
> board, running both the VDR server and xineliboutput and vdr-sxfe.
>
> Come to think of it, I heard codi (xbmp) has support for hardware decoded
> video playback on the A20, and vdr has support for xbmc via
> vdr-plugin-vnsiserver. Is there anybody who has taken this route? How did it
> go?
> http://linux-sunxi.org/XBMC
> http://kodi.wiki/view/VDR
>
> the other route I heard of is VDR+softhddevice via vdpau and cedarX. Has
> anybody got this running on an A20? Does it actually yields accelerated
> video playback?
>
> I have managed to use mplayer to playback my recordings using cedarX, but
> that's some time ago:
> https://www.olimex.com/forum/index.php?topic=3560.msg14973#msg14973
>
> Kind regards,
> Cedric

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] from xineliboutput to ... perhaps softhdddevice?

[VDR User]

For those of you using Raspberry Pi or Allwinner boards, how is osd
performance? If the osd is fast & smooth, I'm interested in building
a couple vdr setups like those (maybe Raspberry Pi 2. Rpi is just too
slow). Any degrade in performance is a deal-breaker for me.

Thanks

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] from xineliboutput to ... perhaps softhdddevice?

[VDR User]

Gerald, my opinion is my opinion - you disagreeing doesn't change
anything. It's not wrong and nobody is the opinion police.

Reiner, if you don't want to following something, *don't follow it*.
You're not being forced to read anything. However, out of courtesy for
Matthias, the OP, I won't keep participating in distraction from his
query.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] from xineliboutput to ... perhaps softhdddevice?

[VDR User]

> Restfulapi and dynamite were the projects I had in mind, thanks Lars. And
> restfulapi was a starter for even two more fellows.

I've never heard of Restfulapi. Dynamite I've at least heard of but
until Lars post, had no clue what it did.

> And just in case that you will tell now that nobody needs that, then you
> talk only for yourself.

I haven't made any comment at all along those lines. There's
absolutely no reason for you to think that based on anything I've
said. Maybe you're trying to project your own opinions onto me. Or
just making things up and then commenting on it. Who knows.

>Dynamite is used by all yaVDR users.
>Restfulapi is now part of OpenELEC.

They sound successful. Unfortunately
https://github.com/yavdr/vdr-plugin-restfulapi/blob/master/README is
just an advertisement for yavdr and gives no actual information on
what exectly restfulapi does. From what I could find searching
elsewhere, it's just an alternative way to display epg information
(returned as json or xml formatted). Is this correct?

The dynamite plugin sounds like it would help speed up the VDR start
process. I would imagine something like that would be necessary
if/when VDR gets a real server/client upgrade. I would hope so
anyways! I'll probably wait until Lars does the rework he mentioned
before I try it.

> Are you man enough to confess that you are wrong? I doubt that, you will
> surely find some excuses.

What exactly do you think I was wrong about? That I'm "genuinely
curious who you talked into learning to code, and what
projects they've done", or that " I expected nothing more than the
completely predictable response you
gave"? Maybe you're referring to, "people love making claims like that
but hate backing them up"? Nothing I've said is wrong or untrue.
There's nothing to `confess`, as you put it.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] from xineliboutput to ... perhaps softhdddevice?

[VDR User]

On Wed, Apr 15, 2015 at 9:56 AM, Gerald Dachs  wrote:
>>> To not say it and miss a change to get it done is useless.
>> Who, and what have they coded? Project names?
>>
> So, you name me a liar? Would it change something if I would name projects?

I'm genuinely curious who you talked into learning to code, and what
projects they've done. Should've been easy enough to do. But, I
expected nothing more than the completely predictable response you
gave. I doubt anyone did. People love making claims like that but hate
backing them up ... you know, for some reason.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] from xineliboutput to ... perhaps softhdddevice?

[VDR User]

On Wed, Apr 15, 2015 at 8:03 AM, Gerald Dachs  wrote:
>> Proper server/client has been on the user wishlist for ages. There's
>> no reason to be rude to someone looking for something better. If those
>> solutions were all that great then there wouldn't be any reason to
>> ask. Of all the people who are scolded with `code it yourself then`,
>> how many actually can? Probably very very very few, so why bother with
>> such useless comments?
>
> Nonsense, I have not been rude. I have even some examples where I told this
> to other users
> that started coding afterwords. That made it a very useful comment.
>
> To not say it and miss a change to get it done is useless.

Who, and what have they coded? Project names?

Thanks

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] from xineliboutput to ... perhaps softhdddevice?

[VDR User]

On Wed, Apr 15, 2015 at 3:56 AM, Gerald Dachs  wrote:
 While streamdev and VNSI/XVDR solve some of the issues, most notably
 the multi-client dependency, they create new ones. No native OSD with
 VNSI/XVDR, VDR configuration synchronization hassle with streamdev.

>>> use softhddevice + vdr + streamdev-client on the clients and connect to a
>>> streamdev-server on the main vdr.
>>
>> Well, that works so far, but it is not an effective substitute for the
>> functionality of vdr-sxfe,
>> at least not for what I use it mainly. All functions run on the remote
>> machine, and only the screen is
>> transferred to the local machine.
>
> This solution, or the already mentioned possibility with Kodi and vnsi/xvdr,
> are the only supported ways currently.
> If this is not good for you, then start coding.

Proper server/client has been on the user wishlist for ages. There's
no reason to be rude to someone looking for something better. If those
solutions were all that great then there wouldn't be any reason to
ask. Of all the people who are scolded with `code it yourself then`,
how many actually can? Probably very very very few, so why bother with
such useless comments?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr-sxfe or xine-ui ?

[VDR User]

FWIW, everyone I know has switched to softhddevice. I did use
xine-ui/libxine2/vdr-xine a long time ago and it worked fine for me.

On Sat, Apr 11, 2015 at 6:56 AM, Tarik CHOUGUA  wrote:
> Hi, I'm using vdr with xineliboutput plugin.
> When using vdr-sxfe as a frontend, sometimes it reset 
> 'engine_video_frame_buffer' to 250 in the config_xineliboutput file. How can 
> I fix that ?
> I heard that vdr-sxfe is no more supported, and it is better to use xine-ui 
> with libxine2-xvdr. Is that true ?
> Thank you
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] raspbian apt repo with up to date vdr packages?

[VDR User]

Have you tried compiling the sources yourself? It'll probably take a
while but as long as no voodoo/magic is required, I don't see why not.

On Mon, Mar 9, 2015 at 4:33 AM, Torgeir Veimo  wrote:
> I've been testing out VDR on a raspberry pi 2 with excellent result
> using rpihddevice and am wondering if anyone know of any good APT
> repository with up to date packages for VDR and plugins?
>
> Am currently using raspbian which has VDR 1.7.28, so it's a bit behind.
>
>
> --
> -Tor
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Dummy Device PLugin

[VDR User]

>Mar 1 13:05:58 localhost vdr: [8766] ERROR:
/usr/lib/vdr/plugins/libvdr-dummydevice.so.2.0.0: undefined symbol:
_ZN7cDeviceC2Ev

I may be wrong but IIRC I got those kinds of errors when compiling plugins
with a different gcc/g++ than VDR was compiled with.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR version 2.2.0 released - Celebrating 15 years of VDR!

[VDR User]

> Some reader comments in that article seemed to suggest that VDR is becoming
> obsolete due to streaming services and RaaS cloud services
> (recording-as-a-service). Those readers seem to forget two important issues:
> privacy, and availability of service.

Add preference to that list as well. Streaming tv isn't making
anything obsolete, it's simply another option to choose from. VDR has
nothing to worry about, I have no doubt we'll continue to celebrate
development milestones and anniversaries.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] merge 3 recordings of the same show to remove glitches?

[VDR User]

Do you know of any that are capable of frame-accurate h264 editing,
and that don't produce any corrupted frames or artifacts? This
requires several frames around the cut point to be reencoded while the
rest of the frames can be fast-copied.

Thanks

On Thu, Feb 19, 2015 at 9:24 AM, Gerald Dachs  wrote:
> Am 19.02.2015 um 16:42 schrieb VDR User:
>> I'm not aware of any video editing software for Linux
> There is plenty of it:
> - Avidemux
> - Cinerella
> - flowblade
> - Kino
> - Kdenlive
> - LiVES
> - Open Movie Editor
> - OpenShot
> - PiTiVi
> to name only a few.
>
> I use Avidemux, but for merging movies I would try OpenShot
>
> Gerald
>
> !DSPAM:54e61c52441034184121461!
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] merge 3 recordings of the same show to remove glitches?

[VDR User]

I'm not aware of any video editing software for Linux but if you have
access to a Windows box, there are several options (both free & paid):

videoredo
smart cutter
solveigmm video splitter
tmpgenc smart renderer
sony vegas
powerdirector
adobe premiere

Too many to keep listing.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR version 2.2.0 released - Celebrating 15 years of VDR!

[VDR User]

Huge thanks to Klaus and everyone who has contributed over the years
to make VDR the success that it is! The time and effort put into it
has and is greatly appreciated.

See you at the 20 year!
-Derek

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restart of frontend

[VDR User]

>  At yavdr we use this feature to start X and vdr in parallel and attach 
> softhddevice when X is ready.
>  And you can restart X when softhddevice is detached.

Do you happen to know approx. how much startup time is saved doing this?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restart of frontend

[VDR User]

Rather than treating a symptom, why not try to figure out the root
cause of your freezing and address it there?

On Thu, Feb 12, 2015 at 6:38 AM, René  wrote:
> Hi,
>
> First of all i want to thank Klaus for VDR. Vdr has been now "part of my
> life" for roughly 10 years, and i can't imagine myself changing it to
> anything else!
>
> I have finally got time to migrate xineliboutput to softhddevice, but this
> has not been working 100% stable. I have had a couple of screen-freezes and
> screen-blackouts, and the only way to get this fixed was by restarting vdr.
> When using xineliboutput i have solved this by simply restarting my
> windowmanager (lightdm) by using an external command that reloads lightdm..
>
> Is there a way that this could be done from vdr itself, eg by reloading the
> softhddevice-plugin with either an external command without stopping VDR?
>
> Best Regards,
>
> René
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Advice from native speakers needed: To "bisect" or to "halve"?

[VDR User]

>> "adaptive skipping"
>
> The action is skipping, the achievement is searching.
>
> So we do
>
> "Binary Search"
> http://en.wikipedia.org/wiki/Binary_search_algorithm

Searching isn't an achievement (or whatever you mean), it's part of
the skipping process. You `search` (aka look for) the timestamp in
which you want to "skip" to. When it's found, the search stops and the
skip has completed.

Yes, the action is skipping. The skipping is actively modified
therefore the skipping is adaptive:

"Adaptive behavior is a type of behavior that is used to adjust to
another type of behavior or situation."

> Ok, this may be considered informatics phrasing, but this is the unique
> and correct name.

Binary searching is a technical term, and one that I have never heard
associated with or used to describe movement in time. Ask an average
person to define "binary search" and see what kind of response you
get. Klaus asked for a native English speakers response, which I am
and have provided. You're welcome to disagree but that certainly
doesn't make me wrong.

> By the way: So cool that this patch finally finds its way into the core!

This is -do- agree with you on. :)

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Advice from native speakers needed: To "bisect" or to "halve"?

[VDR User]

> The question now is: is "bisect" the right word here, which a native English
> speaker would use? Or should it rather be "halve"? Or something completely
> different?

Bisect isn't correct. Bisecting means to cut something into 2 parts.
Using "halve" doesn't make sense. Binary doesn't either for that
matter. My suggestion is to call it "adaptive skipping".

"adaptive skip value":
Defines the how many seconds to skip forward/back when pressing 1/3.
Valid range is 10-600.

"adaptive skip alternate behavior":
If enabled, adaptive skipping will only adjust the adaptive skip value
with key presses that change the skip direction. Otherwise, the skip
value is halved with every key press.

"adaptive skipping reset":
Defines how long to wait without a key press before resetting the
adaptive skip value back to its original setting.

That to me describes what those do much better. Btw, the definitions
seemed like they could use a touch-up too so I threw in suggestions
for those as well. :)

Regards,
Derek

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] New conf.d support + ONEDIR option. Need opinions.

[VDR User]

>  Klaus forwarded this to vdr-portal.de. I think vdr 2.1.8 will include a 
> patch to add
>
>  ARGSDIR = $(VIDEODIR)/conf.d
>
>  to the ONEDIR case. Because vdr reads all *.conf files from ARGSDIR, you 
> cannot use VIDEODIR because of setup.conf,
> channels.conf etc.
>
>  And I should have documented this feature in more detail (and I will do), as 
> time permits next week.

$(VIDEODIR)/conf.d works fine. That's a little cleaner anyways so
ONEDIR still works as intended, yet conf.d specific files aren't mixed
together with all other *.conf.

Thanks!

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] New conf.d support + ONEDIR option. Need opinions.

[VDR User]

VDR-2.1.7 added the following:

- VDR now reads command line options from *.conf files in
/etc/vdr/conf.d (thanks
  to Lars Hanisch). See vdr.1 and vdr.5 for details.

It seems like this is a welcome change. I plan on moving my command
line options into a single .conf I can share with all my VDR clients
for convenience, and to simplify my tv script. But, I also take
advantage of the ONEDIR option in Make.config because it's easier for
me to keep track of & backup all of VDRs files. And I hate having
files spread all over the place anyways. For those unfamiliar:

# Use 'make ONEDIR=1' to have all data in one single directory:
ifdef ONEDIR
VIDEODIR = /video
CACHEDIR = $(VIDEODIR)
CONFDIR  = $(VIDEODIR)
RESDIR   = $(VIDEODIR)
endif

To stay in line with the idea that ONEDIR actually keeps all data in
one single directory, it makes sense that $ARGSDIR (where the conf.d
files would otherwise go) be included as well. Otherwise, ONEDIR isn't
actually consolidating all VDR data.

I'm proposing adding ARGSDIR = $(VIDEODIR) to the ONEDIR ifdef. If
anyone can think of a good reason not to do this, please voice your
opinion.

Thanks

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Freesat patch

[VDR User]

> b)  With more recent kernels (3.4 and 3.12, I think anything higher than
> 3.0)  I'm seeing regular dmesg events like so
>
> usb 1-1.2: dtv_property_legacy_params_sync: doesn't know how to handle a
> DVBv3 call to delivery system 0
>
> I'm not sure what causes this (no other errors), but it's related to the
> older DVB-T receivers. VDR is built with the same kernel/DVB as the machine
> it runs on.  Is this just a driver issue, or is there a test VDR
> could/should do based on API to avoid making the unhandled DVBv3 call ?

I would assume this question is more appropriate for the linux-media
mailing list. Driver issues are better fixed in the driver rather than
workarounds in an app imo.

-Derek

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Raspberry Pi, Streamdev + rpihddevice

[VDR User]

> Hi, just curious as I have a Rasp running Openelec and xbmc.
>
> What advantages does this software have over the stuff I am using?

My answer would be smaller/lightweight, fast, low system requirements,
no extra junk you may not want/need/use. VDR provides core
functionality and plugins provide the extras you might want. It costs
almost no resources to run VDR + mplayer plugin + mpv-player. With
that I have a full tv/dvr/media player but without any bloat or sql
mess, etc.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Want to have Permashift in your own language?

[VDR User]

> * "Buffer saving blocks rewind"
> (This means that pressing rewind results first in saving of the
> whole buffer and rewinding has to wait for that time. To be
> honest, I found that hard to express that short even in my
> mother language...)

This definitely should be more clear... Something like:

"Save buffer before rewinding"
"Rewind paused during buffer saves"
"Rewinding waits until buffer is saved"

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Forced boot once a day

[VDR User]

 Why don't you just use a cron job for this?

>>> Why to use cron if the ACPI wakeup addon has a setting for this?
>> Because you don't need to bother with a whole plugin just for that.
>>
> It is an addon, no plugin, just some scripts and there is a big chance
> that it is already installed. How else would his computer start to
> record scheduled events?

I misunderstood, I thought it was some plugin. Regardless though it
doesn't take anything special to do what he wants. In addition to a
single line cron, Udo posted what sounds like a good alternative as
well. No extra scripts/packages/whatever necessary.

As far as how he manages `sleeping` and `waking` his system, there's
more than one way to do that so who knows?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Forced boot once a day

[VDR User]

>> Why don't you just use a cron job for this?
>>
> Why to use cron if the ACPI wakeup addon has a setting for this?

Because you don't need to bother with a whole plugin just for that.
But, if the end result is the same then who cares how you got there I
guess. My preference is to not make things more difficult or dependent
than they need to be so for me I wouldn't bother with a plugin when my
system already supports what I'm looking for.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Forced boot once a day

[VDR User]

Why don't you just use a cron job for this?

On Sun, Sep 14, 2014 at 3:02 AM, Thomas Maaß  wrote:
> Hi!
> I use epgsearch's searchtimer to record my favorite series.
> But there could be a problem when using automatic shutdown
> and wakeup. When there is no event in the current epg, the
> searchtimer will not be updated any more. The shutdown script
> will get no wakeup time, because there is no timer. The VDR will
> do no wakeup, and no more searchtimer records will be done.
> Maybe an option could be added to VDR to force a boot once a
> day. When the next timer is later than a specific time, set the
> wakeup time to this time. So you could make sure, that VDR is
> booted once a day, and the searchtimer could be updated. No
> searchtimer recording would be lost.
>
> Thomas
>
> --
> gpg-id: ccdbc2cf
> https://www.setho.org/people
>
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Raspberry Pi, Streamdev + rpihddevice

[VDR User]

>> New problem though, with 1080i atsc, I'm getting screen blanking every 20 
>> seconds or so.  It's fine with 480i with the deinterlacer enabled (as per 
>> the log).  720p also works fine with deinterlacer disabled.  I can't find 
>> anything in the log files that might help with troubleshooting this problem.
>
> There's a HDMI boost option in config.txt you might want to try:
>
> # Config HDMI Boost
> # Configures the signal strength of the HDMI interface. Default is 0. Try 4 if
> # you have interference issues (or blanking or no display) with hdmi.
> config_hdmi_boost=4   #Set to change signal strength (0 - 7)

What exactly is the purpose of that? A way to reduce power consumption
by giving hdmi only enough signal/power it needs per your setup?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Raspberry Pi, Streamdev + rpihddevice

[VDR User]

> I am still struggling howto get accelerated video playback going. Now the A20 
> uses 70% CPU to playback a SD stream. I will look into using the android 
> driver with a linux wrapper around it. It should be doable, somebody on this 
> list reported success (but I didn't ask him for a howto)
>
> The board can be clocked from 90MHz .. 1GHz. I have yet to measure the power 
> consumption, but the chip gets quite hot (about 80 degrees) when running at 
> 1GHz continuously without heat sink.


How stable is it overclocked that high? Also, how long have you been
doing that? I don't know what the thermal tolerance is for the A20 but
doesn't low power design not play nice with high temps? I would think
without adding at least some cooling, overclocking that much will send
it to see the grim reaper much much sooner...?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr on allwinner A20

[VDR User]

That's what I figured. At a very minimum I would need something that
can handle 1080i with a decent deinterlacer used, 1920x1080 hdmi out,
surround sound (via hdmi out). Basically something on par with Nvidia
vdpau. Hardware isn't the problem though, seems the only thing lacking
is the software and maybe in time that will exist/mature.

On Sat, Jun 14, 2014 at 6:43 AM, cedric.dew...@telfort.nl
 wrote:
>
> The video driver is a weak point. It's strong enough to play my SD content 
> with VLC, but not when I enable deinterlacing or postprocessing. It's not at 
> the top of my list to solve, because it's enough for the SD digitenne 
> recordings I have.
> I think the drivers will improve in the future, so I just have to be patient.
> The CPU / USB / SATA is impressive, It's fast enough to record 7 SD streams 
> from 2 different DVB-T receivers, and watch an 8th stream. But this will only 
> work if the storage directory is on a SATA drive, the internal micro SD slot 
> is extremely slow. An apt-get install cycle takes a very long time, even with 
> a class 10 uSD card.
>
> Kind regards,
> Cedric
>
>
>>Origineel Bericht
>>Van : user@gmail.com
>>Datum : 13/06/2014 23:39
>>Aan : cedric.dew...@telfort.nl
>>Onderwerp : Re: Re: [vdr] [solved] allwinner A20: vdr-plugin-sc does compile, 
>>but binary incompatible
>>
>>How does it work so far? I've looked at Allwinner stuff before but I
>>wasn't sure if there were stable drivers for the Mali 400 GPU. I know
>>it can do 1080p, which makes it a good cheap htpc but only if it has
>>stable drivers. I also wondered if it has deinterlacers as well for
>>1080i content. I don't know if the A20 is strong enough to deinterlace
>>with only CPU muscle.
>>
>>On Fri, Jun 13, 2014 at 11:35 AM, cedric.dew...@telfort.nl
>> wrote:
>>>
Origineel Bericht
Van : user@gmail.com
Datum : 13/06/2014 18:05
Aan : vdr@linuxtv.org
Cc : cedric.dew...@telfort.nl
Onderwerp : Re: [vdr] [solved] allwinner A20: vdr-plugin-sc does compile, 
but binary incompatible

On Thu, Jun 12, 2014 at 10:05 PM, jacek burghardt
 wrote:
> So you are running Linux on tablet instead android ? What version of 
> Linux ?

There are plenty of Allwinner-based mini-pc boards out there so it's
easily possible his device is one of those and not a tablet.

>>> You are correct. Its an olimex OLinuXino A20. This is the product page:
>>> https://www.olimex.com/Products/OLinuXino/A20/A20-OLinuXino-MICRO-4GB/open-source-hardware
>>>
>>> It's a debian based image, as can be downloaded here:
>>> https://www.olimex.com/wiki/A20-OLinuXino-MICRO#Linux
>>>
>>> Kind regards,
>>> Cedric
>>
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [solved] allwinner A20: vdr-plugin-sc does compile, but binary incompatible

[VDR User]

On Thu, Jun 12, 2014 at 10:05 PM, jacek burghardt
 wrote:
> So you are running Linux on tablet instead android ? What version of Linux ?

There are plenty of Allwinner-based mini-pc boards out there so it's
easily possible his device is one of those and not a tablet.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] TBS6285 slow onscreen menu

[VDR User]

> Thank you for your suggestion, TBS6285 is not supported yet.
> It has si2168 demodulator and si2158 tuner, both are used by another USB
> card.
>
> I had started to implement it and  found it difficult to me.
> Demodulator code is little bit different and  missing functions there.
>
> This is sad, because card looks like good, low power consumption, low
> profile, 4x tuner.

Maybe you should discuss this card on the linux-media mailing list.
It's possible somebody may already be working on drivers there, or may
be willing to write them if you provide a sample card.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr file system

[VDR User]

XFS isn't your problem. I record to an XFS drive shared over my lan
via nfs and its never crashed or caused problems. If I were you I
would troubleshoot your problem further and find out whats actually
wrong with your system.

On Sun, May 25, 2014 at 6:32 PM, jacek burghardt
 wrote:
> What is the best file system for vdr. I just discovered that recording are
> causing crashes of vdr. I have video mounted on xfs partition and I can play
> live tv. but recording causes constant crashes.
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] converting ts to mkv

[VDR User]

There's no reason to touch the audio/video streams at all unless you
actually want to re-encode them for some reason. If all you want is an
.mkv rather than a .ts, that can be done in seconds with mkvmerge.
Re-encoding in that case is pointless & a waste of time.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] converting ts to mkv

[VDR User]

I already told you:

"You can merge them directly with the mkv container using append. All
you need is the free "mkvmerge" tool."

Maybe you're unaware that ts & mkv are simply containers. Nothing is
converted when you change containers. Put it this way, milk is milk
whether you have it in a glass or a plastic cup.


On Sun, May 25, 2014 at 3:36 PM, jacek burghardt
 wrote:
> I had delete the movie files that had been broken up so badly, but I had few
> recordings that have two files in them. So is it better to convert each ts
> to mkv and merge the mkv ? I set my max recording option tp 30GB.
> I had found an issue with my vdr it crashes when recording tv. i
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] converting ts to mkv

[VDR User]

You can merge them directly with the mkv container using append. All
you need is the free "mkvmerge" tool.

On Sun, May 25, 2014 at 7:20 AM, jacek burghardt
 wrote:
> I had recording setup last night and now I have 111 ts files. I guess heavy
> rain  may caused so many ts files. is there a script that would merge them
> into one ts and convert them into mkv ? How I can setup after recording
> rules to convert recordings ?
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [PATCH] Add SubsystemId for usb cards

[VDR User]

If the linux-media guys every get their act together in that area,
this wouldn't be necessary. Standardized statistics has been discussed
(at length) a number of times but unfortunately nothing was ever
agreed on and merged.

On Sat, May 24, 2014 at 8:12 AM, Jose Alberto Reguero
 wrote:
> This patch add SubsystemId for usb cards, to be able to make changes to
> GetSignalQuality and GetSignalStrength functions.
>
> Jose Alberto
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] shows recording

[VDR User]

> Epgsearch has an option to avoid duplicates, so it would record every
> episode once - no matter how old they are. Is that what you're looking for?
> If not, how can VDR decide if an episode is new or not?

I looked into this ages ago and iirc, there's no sure way for VDR to
know if an episode is new or not. But there are a couple ways you can
attempt it which should work well in most cases.

- Compare the "original air date" with the current date. This is
usually included in the epg info and probably the best way to identify
new episodes.
- Search for "New." in the show summary. This isn't as reliable as
using the original air date, but it's better than nothing as a
secondary method.

To my knowledge nobody has coded a plugin to do this. It would be
great if someone would though!

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Invalid sat cable number errors

[VDR User]

On Thu, Apr 17, 2014 at 1:28 PM, Ville Skyttä  wrote:
> naludump

How much disk space do you actually save using that?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] still image at end of replay

[VDR User]

> Here a little feature request:
>
> Problem: the children are watching a recording, and at the end VDR
> switches to normal live TV, that can be anything. I have to be there at
> the right moment to turn off the screen and the sound, in order to bring
> them to leave the tv-room.
>
> I would be nice, if VDR could turn off the sound at the end of a replay
> and show a still image (e.g. "Children, go to bed now!").
>
> What do you think about that?

Why don't you just tell your kids to turn the tv off when their show
is over? This really sounds like something that should be solved in
parenting and not code.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] skipping 5/10 seconds

[VDR User]

>> Well, that's something we can talk about. You could make it so that during
>> replay the Left and Right keys perform 5s skips, and the FastForward/-Rewind
>> keys (if present on the user's remote control) still retain their normal
>> function.
>
> This kind of behavior sounds like a good compromise and no new keys
> are needed.

Agreed. Although, I still like the idea of users being able to set
their own values.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] skipping 5/10 seconds

[VDR User]

>> What I would be willing to accept is a patch that makes the skip delta of
>> the yellow and green keys (currently a fixed +/-60s) configurable.
>
> Yes, that's fine. But what's the problem with a second skip-value for
> buttons 1 and 3?

If the skip amount can configurable then each user can set it to his
own liking and no extra buttons needed. That seems like the simplest &
best solution in my opinion. Can you think of any setup that actually
uses several skip buttons? Skipping doesn't need to be complicated or
require a handful of buttons. Allow the user to set his preferred
skip+ and skip- amounts, and done deal. :)

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] integrating jumpplay-patch

[VDR User]

>> Btw, instead of asking Klaus to create workarounds for noad problems,
>> why not ask the author of noad to fix his plugin? I'm sure Klaus would
>> suggest the same after stating there's zero chance he will add a
>> "specialworkaroundforwrongmarkfromnoadparameter".
>
> why not just add a parameter stop recording
> on last mark yes/no?

Marks in vanilla VDR are used for editing cut-points, not jumping
during playback. So, rather than ask Klaus to deal with it (since it
has nothing to do with editing), perhaps the appropriate person to
make the request to would be whoever maintains the jumpplay patch.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] integrating jumpplay-patch

[VDR User]

>>> Why is the last mark not correct?
>>
>> hehe, ask noad ;)
>>
.
>>> What about a setup-parameter "jumpplay-dont-stop-on-last-mark"?
>>
>> I prefer a parameter to disable the end on the last mark.
>
> And what do you bet, that Klaus will agree to such a
> "specialworkaroundforwrongmarkfromnoadparameter"...? ;)

That's a suckers bet. ;)

Btw, instead of asking Klaus to create workarounds for noad problems,
why not ask the author of noad to fix his plugin? I'm sure Klaus would
suggest the same after stating there's zero chance he will add a
"specialworkaroundforwrongmarkfromnoadparameter".

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] EPG for BBC TV channels?

[VDR User]

 I have several VDR boxes that all run 24/7 without being restarted
for weeks/months at a time. Even then a restart was only necessary due
to a system update such as kernel or drive update. All of these boxes
use the EEPG plugin and none of them display any kind of memory
problem. I strongly urge anyone who wants to try, or thinks there's a
problem, to grab the latest git source and see if these problems
actually (still) exist.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] EPG for BBC TV channels?

[VDR User]

>> The author of the EEPG plugin has always been very helpful. You should
>> just contact him about adding Freeview HD support. Then you won't have
>> to monkey around with patches and messing with the VDR core.
>
> I think concensus is that the patch's code is cleaner than the plugin's.
> I looked at the plugin code to see if I could work out how to make the
> Huffman decoding work on standard PIDs for Freeview as well as on
> Freesat's non-standard ones, and found it too difficult to follow. The
> original author might not have so much difficulty, but there's also
> quite a big memory leak which somehow defied my efforts to trace it with
> valgrind.

I mentioned this thread to him yesterday. He gave a quick look but
needs someone with access to Freeview HD to provide debug logs & test
since he doesn't have that provider. Also, I've been using the latest
git of EEPG for some time and haven't noticed any big memory leaks.
When is the last time you've tried this plugin?

I used to have to patch the VDR core to get eit working here too. I
must say, it's quite a pleasure to not have to maintain/fix it anymore
now that I can just use EEPG. Even if you don't care about support for
Freeview HD in EEPG, I don't see why you wouldn't just put your patch
into a plugin and never have to hassle with fixing it again. I think
most people prefer not to patch the VDR core at all when it can be
avoided.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] EPG for BBC TV channels?

[VDR User]

>> Freesat uses a Huffman encoding for EGP data, which has not made its
>> way into VDR core.
>>
>> a) Plugin EEPG has these tables (and covers some other EPGs as well)
>> b) A Freesat patch extends VDR to just the Freesat code tables.
>
> The patch also covers Freeview HD (which uses the same encoding as
> Freesat, but with standard PIDs instead of Freesat's custom ones), which
> EEPG doesn't, unless it's been updated since I last used it.

The author of the EEPG plugin has always been very helpful. You should
just contact him about adding Freeview HD support. Then you won't have
to monkey around with patches and messing with the VDR core.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Minimum CPU requirement for xineliboutput + vdr-sxfe for HDTV

[VDR User]

Using VDPAU drops the cpu requires to practically nothing. For
example, my weakest VDR box is running on an Intel Atom 230 1.6ghz
with ION gpu (1st gen). Watching 1080i with temporal-spatial
deinterlace, the cpu hovers around 12%. Even when using software
deinterlacing, it doesn't take a lot of cpu horsepower until you want
to use advanced/high quality deinterlacers.

That being said, it's hard to beat VDPAU. For the cost of about a $30
video card, you can turn an old piece of crap pc collecting dust in
your closet, into a full-blown htpc.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Streaming DVD contents from VDR?

[VDR User]

Why not just dump the dvd iso and play it with the vdr-mplayer plugin?
Or vdr-play plugin is that supports playing iso's directly.

On Sat, Feb 1, 2014 at 12:42 PM, Marko Mäkelä  wrote:
> Hi,
>
> I have a minimal setup consisting of an old PC sitting in a different room,
> and a Samsung SmartTV in the living room. We rarely watch any DVDs in my
> family, so we do not have any dedicated DVD player.
>
> I used to use a DVD player plugin when the VDR PC was in the living room,
> attached to a TV, but I would prefer to have a mostly-headless setup (the
> VDR PC is only hooked to a VGA monitor, no sound output at the moment).
>
> I checked both the Streamdev plugin and the SmartTV plugin, but neither seem
> to support DVDs at the moment:
>
> http://projects.vdr-developer.org/projects/plg-streamdev/
> http://projects.vdr-developer.org/projects/plg-smarttvweb/
>
> I wonder if there is any easy solution to stream the contents of a disk in
> the DVD drive of the VDR PC over the local CAT5e cabling. I guess that an
> alternative solution could be to transcode the DVD into MPEG PS files, which
> could presumably be viewed on or streamed from VDR.
>
> Best regards,
>
> Marko
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [ANNOUNCE] VDR developer version 2.1.3

[VDR User]

Whatever gets implemented, please make sure the user can disable it. I
can't remember why but VDR's internal channel population has never
worked right for NA so it's better to be kept as optional when it
comes to auto-removing channels, parsing si tables, etc.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] xinelib / vdpau suddenly fails to detect Nvidia ION GPU

[VDR User]

> Any idea where I should look? Why might xinelib or vdr-sxfe fail to correctly
> detect the ION (MCP79) chip when everything is unchanged?

The problem is either software or hardware. If you are __100%
certain__ software hasn't changed, logically the issue must be
hardware related. That doesn't necessarily mean your ION is crapping
out. Faulting/flakey power supplies are known to cause any of a wide
range of problems. If you do need to diagnose hardware, start with the
simple things first. Sometimes simply re-seating a connector solves a
problem. Other common considerations are if the gpu is having problems
due to heat -- cooling (case, chipset, any of them) fan died, too much
dust buildup, airway blocked, etc.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] cSoftDevice::StillPicture() not updating video in VDR 2.0

[VDR User]

Oops! I misread softdevice as softhddevice. Sorry for the confusion there.

On Wed, Dec 25, 2013 at 1:17 PM, Marko Mäkelä  wrote:
> On Wed, Dec 25, 2013 at 12:23:23PM -0800, VDR User wrote:
>>
>> If you haven't done so already, please bring this to Johns (author of
>> softhddevice) at the vdrportal forum.
>
>
> I did not yet, because softdevice has little to do with softhddevice.  But
> thanks for the hint, I think I should set up vdr, softhddevice and some
> "dummy tuner" plugin on a more modern system, so that I can compare what is
> different. (I will stick to softdevice+DirectFB on the low-end system that
> is equipped with a budget tuner card.)
>
>
> Marko
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] cSoftDevice::StillPicture() not updating video in VDR 2.0

[VDR User]

If you haven't done so already, please bring this to Johns (author of
softhddevice) at the vdrportal forum.


Thanks

On Wed, Dec 25, 2013 at 6:50 AM, Marko Mäkelä  wrote:
> After upgrading to VDR 2.0, I got Softdevice to almost work (see the mail
> archive a couple of months ago). Sometimes it is showing garbage (really
> random noise) on the MGA350 OSD layer; I can live with that, as this box is
> only used for infrequent recordings.
>
> The last annoying problem is that going to the next or previous I-frame when
> editing (buttons 4 and 6 on the remote control) are not updating the video
> screen at all. Only the edit mark is moving on the OSD layer.  If I press
> Play, it will start playing from the current edit mark. So, it is possible
> but much more clumsy to cut recordings.
>
> SoftDevice is overriding the method with this:
>
> void cSoftDevice::StillPicture(const uchar *Data, int Length)
> {
> SOFTDEB("StillPicture...\n");
> if (decoder)
>   decoder->StillPicture((uchar *)Data,Length);
> }
>
> It seems to me that mpeg2decoder.c in softdevice is creating a new thread
> every time I try to move editing mark, and calling cMpeg2Decoder::Action().
> In gdb, it will fail as follows:
>
>   while(ThreadActive) {
> while (freezeMode && ThreadActive)
>   usleep(5);
>
> BUFDEB("av_read_frame start\n");
>
> if (useAVReadFrame)
> ret = av_read_frame(ic, &pkt);
> else
> ret = av_read_packet(ic, &pkt);
>
> if (ret < 0) {
> BUFDEB("cMpeg2Decoder Stream Error!\n");
> if (ThreadActive)
>usleep(1);
> continue;
> }
>
> useAVReadFrame=true, so it is calling av_read_frame(). That will block when
> running under gdb, like this:
>
> #2  0xb68f83a9 in cSigTimer::Sleep (this=0xb2c121f4, timeoutUS=5,
> lowLimitUS=0) at sync-timer.c:75
> #3  0xb68f1cf0 in cMpeg2Decoder::read_packet (this=this@entry=0xb2c120f0,
> buf=buf@entry=0x87fc5b0
> "v\253T)\251z\366\020[\231a\202\275\237@\006\266\067k*r\370JV\255\364\020\177\247:\353
> \004\024\277\004jhjG|] t$X", buf_size=buf_size@entry=10864) at
> mpeg2decoder.c:1128
> #4  0xb68f1dcf in read_packet_RingBuffer (opaque=0xb2c120f0, buf=0x87fc5b0
> "v\253T)\251z\366\020[\231a\202\275\237@\006\266\067k*r\370JV\255\364\020\177\247:\353
> \004\024\277\004jhjG|] t$X", buf_size=10864)
>at mpeg2decoder.c:1042
> #5  0xb69140c9 in fill_buffer (s=s@entry=0x85ac040)
>at libavformat/aviobuf.c:319
> #6  0xb6916ff7 in get_byte (s=0x85ac040) at libavformat/aviobuf.c:365
> #7  get_byte (s=s@entry=0x85ac040) at libavformat/aviobuf.c:360
> #8  0xb6958984 in find_next_start_code (header_state=0x8a075e0,
> size_ptr=, pb=0x85ac040) at libavformat/mpeg.c:142
> #9  mpegps_read_pes_header (s=s@entry=0x89f2080, ppos=ppos@entry=0xb10cc190,
> pstart_code=pstart_code@entry=0xb10cc160, ppts=ppts@entry=0xb10cc170,
> pdts=pdts@entry=0xb10cc180) at libavformat/mpeg.c:246
> #10 0xb695933a in mpegps_read_packet (s=0x89f2080, pkt=0xb10cc290)
>at libavformat/mpeg.c:419
> #11 0xb690c3b4 in av_read_packet (s=s@entry=0x89f2080,
> pkt=pkt@entry=0xb10cc290) at libavformat/utils.c:591
> #12 0xb690ce8b in av_read_frame_internal (s=0x89f2080, pkt=0xb10cc304)
>at libavformat/utils.c:998
> #13 0xb68f2527 in cMpeg2Decoder::Action (this=0xb2c120f0)
>at mpeg2decoder.c:1228
>
> It will unblock when I hit 4 or 6 again, because the thread would be killed
> (ThreadActive=false) by this:
>
> #0  cMpeg2Decoder::Stop (this=this@entry=0xb2c120f0,
> GetMutex=GetMutex@entry=false) at mpeg2decoder.c:1545
> #1  0xb68f2cec in cMpeg2Decoder::Clear (this=0xb2c120f0) at
> mpeg2decoder.c:1655
> #2  0xb68ea1b6 in Clear (this=0x83d3130) at softdevice.c:492
> #3  cSoftDevice::Clear (this=0x83d3130) at softdevice.c:484
> #4  0x080cf2da in cDvbPlayer::Empty() ()
> #5  0x080cf7e9 in cDvbPlayer::Goto(int, bool) ()
> #6  0x080d1303 in cDvbPlayerControl::Goto(int, bool) ()
> #7  0x080fd676 in cReplayControl::MarkMove(bool) ()
> #8  0x080fdcc6 in cReplayControl::ProcessKey(eKeys) ()
> #9  0x080aac39 in main ()
>
> I wonder why this worked in VDR 1.6 but no longer in VDR 2.0? Is it because
> Softdevice is expecting a PES packet here instead of TS, or is it something
> else?
>
> Marko
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] [Announce] streamdev-0.6.1

[VDR User]

On Sat, Nov 30, 2013 at 3:30 PM, Frank Schmirler  wrote:
>> I have been using the VDR Samsung SmartTV VDR plugin which relies on
>> streamdev for transfer of live channels over the network and it uses
>> its own proprietary implementation for the transfer of recordings. I
>> have tried using it over wifi as well as powerline. The recordings
>> (SD and HD) play flawlessly over the network, however the streaming
>> of live channels using streamdev results in regular buffering (SD
>> and HD) and eventually the TV just gives up playing them. Is there
>> any buffer options or other configurable settings within streamdev
>> that might alleviate this problem? I can't seem to find much that
>> would help.
>
> Maybe you suffer from some sort of network congestion. Currently there's no
> buffering option. Streamdev starts streaming as soon as possible. Try adding a
> short delay at the beginning of  void cStreamdevWriter::Action(void) in file
> server/streamer.c, e.g. cCondWait::SleepMs(500);

If his recordings stream fine and the problem is only with live tv,
how could that possibly be network congestion?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] start VDR without hardware for test and tutorial

[VDR User]

Have you tried patching VDR so it doesn't abort if no dvb device is
found? I'm not sure what side-effects, if any, there may be by doing
so.

Btw, I also found it annoying VDR wouldn't start without a dvb device.
A long time ago I had a dvb card die but i had a lot of unwatched
recordings so I figured I would just watch those until my new dvb card
came in. Nope! Pretty lame when you run VDR on a dedicated box with no
keyboard attached and no easy way to get that box to play your
recordings. IMO VDR should start regardless. What good is there in
denying the user access to his recordings and plugins? Obviously no
dvb device means no live tv, but VDR does/can do a lot more than that.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Really stupid question about Full-Function DVB Cards

[VDR User]

You can also just buy a really cheap VDPAU capable Nvidia video card.
For about $25 you can have full HD support using VDPAU hardware
decoding.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr 1.7 -> 2.1 upgrade tips (FHS)

[VDR User]

>> To me, dumping files all over the drives is messy, sloppy, and bad
>> practice. Always has been and always will be. Someone just wants to copy
>> MS stupidity into linux.
>
> I think some features from the FHS predate Windows and even Microsoft.
> Having every file belonging to an application in the same place is
> insecure and makes it more difficult to support things like multiple
> users or one user with multiple PCs, especially if some of them are thin
> clients.

In my case every one of my vdr boxes are dedicated single-user htpcs.
For me, having all of vdrs files in one location makes backups very
easy to create & restore. Additionally, navigating to whatever file I
need is simple -- no hunting or trying to remember what is where. My
only big wish as far as setup goes is vdr getting real & solid
server/client support, and the good news there is that unless things
have changed, it's actually on Klaus's TODO list. But anyways, thanks
to ONEDIR and LCLBLD, I can completely ignore FHS with no hassle at
all.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] vdr 1.7 -> 2.1 upgrade tips (FHS)

[VDR User]

>> Hi,
>> Have a look to Make.config.template if you want to use vdr 2.x like 1.6
>> running in one single dir!
>
> Yeah, I saw that sort of thing is doable but it's probably worth my
> while doing things "properly" to fit in with the current way of
> thinking.

It's not `improper` to keep the same pre-FHS structure. A lot of
people don't care about FHS. I personally don't like files spread out
all over the place. Instead I prefer things be kept in a single
location so things are easy to keep track of. For that reason, I also
use ONEDIR=1 in my vdr Make.config. I didn't have to move any files
anywhere and upgraded VDR with no problem.

Don't do something because someone else does it. Do it because it's
what you actually want. If you don't want it that way, why force
yourself to go against your own preference? Especially if you're using
linux where anything goes.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Trouble with softdevice -vo dfb:mgatv OSD with vdr 2.0.4

[VDR User]

Have you tried softhddevice for output?
http://projects.vdr-developer.org/git/vdr-plugin-softhddevice.git/

On Sun, Nov 3, 2013 at 2:42 PM, Marko Mäkelä  wrote:
> On Sun, Nov 03, 2013 at 10:01:54PM +0200, Marko Mäkelä wrote:
>>
>> On Fri, Nov 01, 2013 at 11:19:48PM +0200, Marko Mäkelä wrote:
>>>
>>> If I change the assignment to isTrueColor=false, the square goes away and
>>> I will get the familiar gray rectangles on the screen (from the "else" block
>>> that I omitted above).
>>
>>
>> I did some further studying. The truecolor OSD was implemented early 2011.
>> As far as I understand, the softdevice plugin is converting palette-based
>> bitmaps into an ARGB layer. There is a comment at the end of the definition
>> of class cOsd in osd.h that shows how the conversion should be done.
>>
>> It looks like I should simply follow this example, possibly implementing
>> some kind of threshold mapping on the Alpha channel in case the Matrox does
>> not implement 8-bit translucency but just a 1-bit transparency flag. So, I
>> will try to remove the palette mapping from SoftOsd.c and replace the
>> GetBitmap() call with the RenderPixmaps() loop.
>
>
> I figured this out for the most part. The pixmap gets first converted to an
> ARGB buffer cSoftOsd::OSD_Bitmap in FlushPixmaps() and DrawConvertPixmap().
> From OSD_Bitmap it gets converted to the screen memory. I did not change the
> latter conversion.
>
> Maybe I did something wrong regarding DirtyDrawPort and DirtyViewport,
> because I got occasional crashes when activating the OSD. When using a
> full-screen OSD (filling the entire 1280×1024 panel) the bottom 4 or so
> lines were never erased.
>
> I did not get to see DVB subtitles yet, either due to them not being present
> in the live sendings at the moment I tested, or due to misconfiguration. I
> guess that VDR 2.0 would allow the subtitles to be alpha-blended with the
> OSD layer.
>
> My patch against softdevice-cvs is attached. I compiled it with the
> following:
>
> vdr 2.0.4
> ffmpeg 0.5.13
> DirectFB 1.0.1
> DFB++ 1.0.0
>
> Best regards,
>
> Marko
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] no image with TeVii S464

[VDR User]

If you always have a good signal with your Nexus then the problem is
not the lnb or cable. BTW, unfortunately the signal meter is
unreliable for a lot of cards because they don't follow a standardized
metric. It works for some cards, for others it's basically useless.

Other things to consider...  Is the driver for your TeVii S464 known
to be good/solid/stable? If not, the driver might be to blame. Is your
card correctly detected by the driver or do you have to manually tell
it which card you're using? Is the tuner on the card overheating? If
the copper core wire was cut too short, it can cause inconsistent
signal with some connectors, or no signal at all even if it works fine
with a different connector.

Basically there is not enough information to know the source of your
issue. You've got to do further investigation.

On Sun, Oct 27, 2013 at 8:12 AM, Sergio Daniel Gomez
 wrote:
> El 27/10/13 11:11, Peter Münster escribió:
>
>> Hi,
>>
>> This is probably not a VDR problem, but I guess that here are people who
>> could help perhaps.
>>
>> I use the femon plugin to check the signal, and there is only some 20%
>> of the first line (red), when I test my brand new TeVii S464, and no
>> image.
>>
>> When I replace the card with my old
>> "Technotrend/Hauppauge WinTV Nexus-S rev2.X", I get green signals and an
>> image, so it seems that everything is fine with my dish.
>>
>> Is there some configuration issue, or is this new card just broken?
>> Or do I need another LNB?
>>
>> TIA for any hints,
>>
>
> Hi.
> 20% it's poor signal. To check lnb you can put your hand between dish and
> lnb, signal must to change. If not, the problem it's with lnb.
> Regards.
>
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Fix SIGNALSTRENGTH in vdr 2.0.3 TechniSat SkyStar 2 DVB-S rev 2.3P - dvbdevice.c

[VDR User]

Shouldn't something like this be fixed in the driver?

On Sat, Oct 12, 2013 at 2:08 PM, Klaus Schmidinger
 wrote:
> On 12.10.2013 21:21, knap.home wrote:
>>
>> With this change to the source I was able to run properly "SIGNAL
>> STRENGTH."
>>
>> Using the device Netsystem TechniSat SkyStar 2 DVB-S rev 2.3P.
>>
>> Great as a solution ...
>>
>> Modified Source -> /usr/local/src/vdr-2.0.3/dvbdevice.c
>
>
> Please send just the differences (diff -u) between the original and the
> modified code. I'm afraid even though I tried I can't seem to generate
> a proper diff from what you've posted. And please send it as an attachment,
> not inline (lines get wrapped).
>
> Klaus
>
> ___
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR jumps to old position after ff/rew

[VDR User]

I believe that's a problem with the video decoder. I had the same problem
using vdpau with vdr-xine long ago but it was quickly fixed. When I started
testing vdr-softhddevice, the problem re-appeared. You can enable "CONFIG
+= -DH264_EOS_TRICKSPEED" in vdr-softhddevice/Makefile and it should work,
assuming you're using vdr-softhddevice & are using a recent git of it.


On Tue, Aug 27, 2013 at 9:51 AM, Stefan Schallenberg wrote:

> Hi all,
>
> I detected a strange behaviour in VDR 2.0.2:
> When I replay a recording and press right for fast forwarding and after
> some time press "up" to continue playing at this position vdr jumps back to
> the position where I started the forwarding. I would expect it to continue
> replay at the position where I forwarded to.
>
> Is this a known bug or do I have to press other keys or is there a setting
> to change it?
>
> Stefan
>
> __**_
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-**bin/mailman/listinfo/vdr
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] VDR needs some way to detect new tuners on runtime...

[VDR User]

On Wed, Aug 21, 2013 at 2:40 AM, cedric.dew...@telfort.nl <
cedric.dew...@telfort.nl> wrote:

> I have 3 USB receivers. Sometimes my cat runs over the cables, and in some
> cases causes one receiver to be loose. I would like VDR to be able to start
> in that situation, and not wait until all adapters are connected. This
> would mean I won't be able to record -and even worse watch- anything until
> I figure out the receiver is loose. I know I should guard my receivers so
> they don't go loose, but this is not always as easy as it sounds :-)
>

You want to be able to start VDR without any dvb devices, right?

A bit offtopic, but related is the following situation: When VDR is
> recording something from my USB DVB-T receiver, and I unplug it, this USB
> port does not work anymore until the program that is using the receiver is
> stopped. In this situation, I would like VDR to recognize something is
> wrong, and stop using the receiver. Then the kernel can de-initialize the
> receiver, and when I re-plug the receiver, the kernel can initialize it
> again. Then It would be nice if VDR recognises the new receiver, and starts
> using it.
>

I seem to remember this type of dynamic/hotplug capability being discussed
some time ago in regards to the new server/client design upgrade. If I'm
remembering correctly, I believe this is already on the todo list for that
upgrade.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr