Re: [vdr] Restoring recordings from image
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,)==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
Re: [vdr] vdr Digest, Vol 161, Issue 4
> 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
> >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
> 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
Thanks Klaus & all contributors to VDR! On Sun, Apr 15, 2018 at 3:44 AM, Karim AFIFI <karim.af...@laposte.net> 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
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 <tl...@vorgon.com> 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
> 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
>> 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
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 <listacco...@e-tobi.net> 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
http://linuxscripter.blogspot.com/2012/03/how-to-disable-fsck-on-reboot.html On Mon, May 8, 2017 at 6:41 AM, g.bruno <g.br...@t-online.de> 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
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
<klaus.schmidin...@tvdr.de> 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)?
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)?
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)?
> 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)?
> 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)?
> 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)?
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
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
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
Re: [vdr] Skinflatplus plugin Channel Logo Names
> 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
png ___ vdr mailing list vdr@linuxtv.org https://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Help debugging a segfault cause
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 <cDll::Load(bool)+41>, 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
>>> 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
> 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
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 <matth...@bodenbinder.de> 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
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
<b3hrooz.ram3z...@gmail.com> 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"
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 <li...@keynet-technology.com> 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 <li...@keynet-technology.com> >> 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"
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 <li...@keynet-technology.com> 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
> 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
>> 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
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
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] Media (.mkv) player on Raspberry Pi2 VDR client
>> 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] [PLUGIN] pulsecontrol - configure Pulseaudio via vdr's OSD
This sounds like a very useful plugin. Thanks for your work! On Sat, Dec 26, 2015 at 3:30 AM, Lars Hanisch <d...@flensrocker.de> 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
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 <listacco...@e-tobi.net> 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
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
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?
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?
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 cedric.dew...@telfort.nl 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?
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?
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?
On Wed, Apr 15, 2015 at 3:56 AM, Gerald Dachs v...@dachsweb.de 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] from xineliboutput to ... perhaps softhdddevice?
On Wed, Apr 15, 2015 at 8:03 AM, Gerald Dachs v...@dachsweb.de 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?
On Wed, Apr 15, 2015 at 9:56 AM, Gerald Dachs v...@dachsweb.de 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] vdr-sxfe or xine-ui ?
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 tarik.chou...@yahoo.fr 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?
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 torgeir.ve...@gmail.com 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
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!
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] [ANNOUNCE] VDR version 2.2.0 released - Celebrating 15 years of VDR!
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] merge 3 recordings of the same show to remove glitches?
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] merge 3 recordings of the same show to remove glitches?
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 v...@dachsweb.de 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] Restart of frontend
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
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é linu...@hertell.com 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?
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?
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.
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-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
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
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?
* 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
Why don't you just use a cron job for this? On Sun, Sep 14, 2014 at 3:02 AM, Thomas Maaß m...@setho.org 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] Forced boot once a day
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] Raspberry Pi, Streamdev + rpihddevice
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
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
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 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 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 jaceksburgha...@gmail.com 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
On Thu, Jun 12, 2014 at 10:05 PM, jacek burghardt jaceksburgha...@gmail.com 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
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] converting ts to mkv
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] vdr file system
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 jaceksburgha...@gmail.com 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] shows recording
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] [PATCH] Add SubsystemId for usb cards
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 jaregu...@telefonica.net 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] Invalid sat cable number errors
On Thu, Apr 17, 2014 at 1:28 PM, Ville Skyttä ville.sky...@iki.fi 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
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
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] integrating jumpplay-patch
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] integrating jumpplay-patch
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] EPG for BBC TV channels?
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?
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
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?
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ä marko.mak...@iki.fi 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
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
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
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ä marko.mak...@iki.fi 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=synthetic pointer, 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] cSoftDevice::StillPicture() not updating video in VDR 2.0
Oops! I misread softdevice as softhddevice. Sorry for the confusion there. On Wed, Dec 25, 2013 at 1:17 PM, Marko Mäkelä marko.mak...@iki.fi 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] start VDR without hardware for test and tutorial
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] [Announce] streamdev-0.6.1
On Sat, Nov 30, 2013 at 3:30 PM, Frank Schmirler v...@schmirler.de 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] Really stupid question about Full-Function DVB Cards
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)
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)
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
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ä marko.mak...@iki.fi 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
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 sergiogo...@tostado.com.ar 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
Shouldn't something like this be fixed in the driver? On Sat, Oct 12, 2013 at 2:08 PM, Klaus Schmidinger klaus.schmidin...@tvdr.de 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
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 in...@nafets.dewrote: 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/vdrhttp://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...
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
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On Tue, Aug 20, 2013 at 1:20 AM, Manuel Reimer manuel.rei...@gmx.de wrote: NUMADAPTERS=3 while [[ `find /dev/dvb -name 'adapter*' | wc -l` -lt $NUMADAPTERS ]]; do sleep 1; done runvdr ... could be used to count the number of adapters, and check that number in a loop against the expected number of adapters. This works for *one* system and only if the user manually sets the number of adapters. How could this be done in a automagic way to allow users to just plug the tuner and reboot? I don't think you can automate that in a very reliable way, especially if you're using usb dvb devices and/or devices with field values that aren't set correctly. The only reliable way is to have the user define how many dvb devices are expected to init, and then wait for that to happen during boot. Something like: dvbcount=3 until (($dvbcount == $(ls -d /dev/dvb/adapter* |wc -l))); do sleep 1; done Additionally I would add a timeout if you plan on doing this during boot: dvbcount=3 timeout=60 until (($dvbcount == $(ls -d /dev/dvb/adapter* |wc -l) || timeout == 0)); do sleep 1; ((timeout--)); done ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Deactivate a Tuner
Serial number, assuming that field is used correctly in that device.
On Tue, Aug 20, 2013 at 9:48 AM, Brian-Imap brian_dorl...@t-online.dewrote:
On 8/20/2013 6:28 PM, Brian-Imap wrote:
On 8/19/2013 11:10 PM, Marc wrote:
On 19/08/2013 21:11, Brian-Imap wrote:
On 8/18/2013 8:15 PM, Marc wrote:
On 18/08/2013 19:27, Brian-Imap wrote:
Hi,
so I tried to look for some kind of info to help me identify the tuners,
this is the most interesting bit I guess:
VDR-test-cellar (SDB1): udevadm info --query=all
--name=/dev/dvb/adapter1/frontend0 --attribute-walk
looking at device
'/devices/pci:00/:00:0d.0/:02:00.0/dvb/dvb1.frontend0':
KERNEL==dvb1.frontend0
SUBSYSTEM==dvb
DRIVER==
You can use this command :
udevadm info -a -p $(udevadm info -q path -n /dev/your/path)
to get the complete tree and watch if you can differentiate your front end
with one or more attributes of the subsystems.
Marc.
VDR-test-cellar (SDB1): udevadm info --query=all
--name=/dev/dvb/adapter0/frontend0 --attribute-walk
looking at device
'/devices/pci:00/:00:0d.0/:02:00.0/dvb/dvb0.frontend0':
KERNEL==dvb0.frontend0
SUBSYSTEM==dvb
DRIVER==
VDR-test-cellar (SDB1): udevadm info --query=all
--name=/dev/dvb/adapter2/frontend0 --attribute-walk
looking at device
'/devices/pci:00/:00:0d.0/:02:00.0/dvb/dvb2.frontend0':
KERNEL==dvb2.frontend0
SUBSYSTEM==dvb
DRIVER==
VDR-test-cellar (SDB1): udevadm info --query=all
--name=/dev/dvb/adapter3/frontend0 --attribute-walk
looking at device
'/devices/pci:00/:00:06.0/:01:06.0/dvb/dvb3.frontend0':
KERNEL==dvb3.frontend0
SUBSYSTEM==dvb
DRIVER==
VDR-test-cellar (SDB1): udevadm info --query=all
--name=/dev/dvb/adapter4/frontend0 --attribute-walk
looking at device
'/devices/pci:00/:00:0d.0/:02:00.0/dvb/dvb4.frontend0':
KERNEL==dvb4.frontend0
SUBSYSTEM==dvb
DRIVER==
At the moment I cannot find anything to identify the 4 Tuners on the Cine
S2, the FF on 01:06 is easy.
I got hit by tuning problems a few days ago as the tuner without a cable
was given FE3/0. The FF got FE4/0
at that time. I'm wondering if the DDBridge driver will always number in
the correct order.
So I guess I'll try to make the FF FE0/0, and hope that the DDBRidge
driver will do the rest.
Cheers Brian
___
vdr mailing
listvdr@linuxtv.orghttp://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
___
vdr mailing
listvdr@linuxtv.orghttp://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Hi,
well Its exactly what I was doing, and I cant see a difference. Here an
example of two of the Cine S2 Tuners:
VDR-test-cellar (SDB1): udevadm info -a -p $(udevadm info -q path -n
/dev/dvb/adapter3/frontend0)
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device
'/devices/pci:00/:00:0d.0/:02:00.0/dvb/dvb3.frontend0':
KERNEL==dvb3.frontend0
SUBSYSTEM==dvb
DRIVER==
looking at parent device '/devices/pci:00/:00:0d.0/:02:00.0':
KERNELS==:02:00.0
SUBSYSTEMS==pci
DRIVERS==DDBridge
ATTRS{irq}==16
ATTRS{subsystem_vendor}==0xdd01
ATTRS{broken_parity_status}==0
ATTRS{class}==0x048000
ATTRS{consistent_dma_mask_bits}==32
ATTRS{dma_mask_bits}==32
ATTRS{local_cpus}==ff
ATTRS{device}==0x0003
ATTRS{enable}==1
ATTRS{msi_bus}==
ATTRS{local_cpulist}==0-7
ATTRS{vendor}==0xdd01
ATTRS{subsystem_device}==0x0020
looking at parent device '/devices/pci:00/:00:0d.0':
KERNELS==:00:0d.0
SUBSYSTEMS==pci
DRIVERS==pcieport
ATTRS{irq}==40
ATTRS{subsystem_vendor}==0x10de
ATTRS{broken_parity_status}==0
ATTRS{class}==0x060400
ATTRS{consistent_dma_mask_bits}==32
ATTRS{dma_mask_bits}==32
ATTRS{local_cpus}==ff
ATTRS{device}==0x0378
ATTRS{enable}==2
ATTRS{msi_bus}==1
ATTRS{local_cpulist}==0-7
ATTRS{vendor}==0x10de
ATTRS{subsystem_device}==0x
looking at parent device '/devices/pci:00':
KERNELS==pci:00
SUBSYSTEMS==
DRIVERS==
VDR-test-cellar (SDB1): udevadm info -a -p $(udevadm info -q path -n
/dev/dvb/adapter4/frontend0)
Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.
looking at device
'/devices/pci:00/
Re: [vdr] Is there somewhere a SETUP/INSTALL doc for VDR ?
VDR 2.x so far is really no different from 1.7.x so if you can manage to get 1.7.x working, 2.x shouldn't be a problem. Also, you don't really need a howto. Just get the source, install whatever dependencies are needed, compile, and enjoy! On Tue, Aug 13, 2013 at 12:11 PM, Stephan Loescher loesc...@gmx.de wrote: Hi! The documentation you mentioned here describes vdr 1.7 It works wonderful, but as my Linux/VDR becomes more and more outdated, I tried to setup a new VDR with VDR 2.0 Are there already any howtos for vdr 2.0 and xineliboutput and HDTV? (Or any other frontend, which can be used for HD without a FF-card.) I have managed already to startup this combination, but in replay-mode when I jump forward/backward one minute or do fast-forward/-backward, then everything hangs, but only with HD recordings. SD works fine. Or am I the first one, who tries vdr 2.0 and xineliboutput? ;-) Regards, Stephan. Am 08/12/13 12:52, schrieb cedric.dew...@telfort.nl: [...] There is some documentation here, but it's written for arch linux, so it can work different for a different distro: https://wiki.archlinux.org/**index.php/VDRhttps://wiki.archlinux.org/index.php/VDR https://wiki.archlinux.org/**index.php/VDR#Streaming_VDRhttps://wiki.archlinux.org/index.php/VDR#Streaming_VDR For encrypted DVB-T, see this document: https://wiki.archlinux.org/**index.php/Digitennehttps://wiki.archlinux.org/index.php/Digitenne If you have any questions that are not answered in the above documents, please let me know, so I can improve on those documents. Please feel free to copy and modify these documents so they match your distro, and then submit them to the sites you have searched. This can be a great help for the next person seeking the same information. Best regards, Cedric __**_ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-**bin/mailman/listinfo/vdrhttp://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 and raspberry pi
On Thu, May 30, 2013 at 9:39 AM, Lucian Muresan luci...@users.sourceforge.net wrote: There's now experimental support for libxine, so you can use xineliboutput with vdr-sxfe. See here; http://www.vdr-portal.de/board18-vdr-hardware/board98-arm-co/118588-rasperry-pi-xine-plugin/ Google translate should let get the gist of details required to try it out. FYI, a note before bothering to try to translate the information: So far, the author didn't care to release any sources, so if you do not use the right distribution with exact matching libxine and libc on your raspberry, you're out of luck at this moment. However, he sort of promised to release sources at some point, but doing the way he does, feedback will be limited to those who can effectively try his blob, and he denies himself help from developer-skilled users, which means it can take some long time until his sources will be in shape so he accepts to release them... Maybe a better solution would be to supply Rnissl or Johns a Raspberry Pi to add support to vdr-xine/softhddevice respectively. It's easily worth the $35 imo. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
On Mon, Apr 22, 2013 at 5:33 AM, Klaus Schmidinger klaus.schmidin...@tvdr.de wrote: I think I would be interested to have possibility for multiple positioners later, if VDR would only support it. There doesn't seem to be such a big demand for multiple positioners, so I guess I'll take the easy way and assume there is only one. For the sake of future-proofing, maybe the motor stuff can be added in such a way that it wouldn't take a total rewrite to support multi-motor setups in the event it's decided later on such support would be advantageous. Since motor support is finally arriving, we don't want to undershoot (although single motor setups certainly seem like the easy majority). Another consideration is what setups will look like once VDR advances into server/client design. Will those setups be more likely to have multiple motors? I dunno, but it's worth asking imo. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] RFC: one or many positioners?
I don't have a dish motor myself but FWIW I know a few people who do and they all have only one in their setup. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
