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

2018-04-15 Thread VDR User
Thanks Klaus & all contributors to VDR!

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

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


Re: [vdr] Channels getting deleted on new scan

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

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

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


Re: [vdr] VDR not cleaning .del directories

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

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

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


Re: [vdr] VDR locking up

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

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

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


Re: [vdr] VDR locking up

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

Same here.

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

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

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


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

2017-06-18 Thread VDR User
Thanks for the update. Explains why I haven't been able to connect
just now. Hopefully the repos are ok!

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

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


Re: [vdr] : fdisk preventing quick recordings

2017-05-08 Thread VDR User
http://linuxscripter.blogspot.com/2012/03/how-to-disable-fsck-on-reboot.html

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

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


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

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



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

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


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

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

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

-Derek

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


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

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

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

-Derek

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


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

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

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

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


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

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

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

-Derek

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


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

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

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

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

-Derek

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


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

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

-Derek

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


Re: [vdr] VDR locking up

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

-Derek

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


[vdr] VDR locking up

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

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

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

Re: [vdr] Skinflatplus plugin Channel Logo Names

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

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

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

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


Re: [vdr] Skinflatplus plugin Channel Logo Names

2016-09-17 Thread VDR User
png

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


[vdr] Help debugging a segfault cause

2016-09-08 Thread VDR User
Hi,

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

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

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

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


Re: [vdr] broken recordings

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

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

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


Re: [vdr] broken recordings

2016-08-19 Thread VDR User
> Sorry for interrupting with stupid questions.. Would'nt a NAS do a better
> job in this case?

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

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


Re: [vdr] broken recordings

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

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

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


Re: [vdr] Error in compile softhddevice

2016-07-02 Thread VDR User
The official softhddevice git is outdated for most people it seems.
You'll have to patch it for newer ffmpeg support.

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

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

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


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

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

On Wed, Jun 15, 2016 at 11:52 AM, Richard F <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"

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

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

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


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

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

It's always no problem until something breaks..

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

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

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

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

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


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

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

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

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

I didn't say anything about hardware support.

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

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

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

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

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

Do you have any idea how completely foolish that sounds?

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

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

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


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

2016-02-10 Thread VDR User
Gerald,

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

==

Nicolas,

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

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


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

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

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


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

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

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

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


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

2015-12-26 Thread VDR User
This sounds like a very useful plugin. Thanks for your work!

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

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


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

2015-12-12 Thread VDR User
Thanks for all your work! The site is a great resource for the VDR community!

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

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


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

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

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


Re: [vdr] watching DVDs

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

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


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

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

Thanks

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


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

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



On Fri, Apr 17, 2015 at 11:17 AM, Cedric de Wijs
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?

2015-04-16 Thread VDR User
 Restfulapi and dynamite were the projects I had in mind, thanks Lars. And
 restfulapi was a starter for even two more fellows.

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

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

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

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

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

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

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

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

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


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

2015-04-16 Thread VDR User
Gerald, my opinion is my opinion - you disagreeing doesn't change
anything. It's not wrong and nobody is the opinion police.

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

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


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

2015-04-15 Thread VDR User
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?

2015-04-15 Thread VDR User
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?

2015-04-15 Thread VDR User
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 ?

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

On Sat, Apr 11, 2015 at 6:56 AM, Tarik CHOUGUA 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?

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

On Mon, Mar 9, 2015 at 4:33 AM, Torgeir Veimo 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

2015-03-01 Thread VDR User
Mar 1 13:05:58 localhost vdr: [8766] ERROR:
/usr/lib/vdr/plugins/libvdr-dummydevice.so.2.0.0: undefined symbol:
_ZN7cDeviceC2Ev

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


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

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

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

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


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

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

See you at the 20 year!
-Derek

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


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

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

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

Too many to keep listing.

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


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

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

Thanks

On Thu, Feb 19, 2015 at 9:24 AM, Gerald Dachs 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

2015-02-14 Thread VDR User
  At yavdr we use this feature to start X and vdr in parallel and attach 
 softhddevice when X is ready.
  And you can restart X when softhddevice is detached.

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

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


Re: [vdr] Restart of frontend

2015-02-12 Thread VDR User
Rather than treating a symptom, why not try to figure out the root
cause of your freezing and address it there?

On Thu, Feb 12, 2015 at 6:38 AM, René 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?

2015-02-06 Thread VDR User
 adaptive skipping

 The action is skipping, the achievement is searching.

 So we do

 Binary Search
 http://en.wikipedia.org/wiki/Binary_search_algorithm

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

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

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

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

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

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

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

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


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

2015-02-05 Thread VDR User
 The question now is: is bisect the right word here, which a native English
 speaker would use? Or should it rather be halve? Or something completely
 different?

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

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

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

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

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

Regards,
Derek

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


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

2015-02-01 Thread VDR User
  Klaus forwarded this to vdr-portal.de. I think vdr 2.1.8 will include a 
 patch to add

  ARGSDIR = $(VIDEODIR)/conf.d

  to the ONEDIR case. Because vdr reads all *.conf files from ARGSDIR, you 
 cannot use VIDEODIR because of setup.conf,
 channels.conf etc.

  And I should have documented this feature in more detail (and I will do), as 
 time permits next week.

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

Thanks!

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


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

2015-01-29 Thread VDR User
VDR-2.1.7 added the following:

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

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

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

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

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

Thanks

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


Re: [vdr] Freesat patch

2014-12-31 Thread VDR User
 b)  With more recent kernels (3.4 and 3.12, I think anything higher than
 3.0)  I'm seeing regular dmesg events like so

 usb 1-1.2: dtv_property_legacy_params_sync: doesn't know how to handle a
 DVBv3 call to delivery system 0

 I'm not sure what causes this (no other errors), but it's related to the
 older DVB-T receivers. VDR is built with the same kernel/DVB as the machine
 it runs on.  Is this just a driver issue, or is there a test VDR
 could/should do based on API to avoid making the unhandled DVBv3 call ?

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

-Derek

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


Re: [vdr] Raspberry Pi, Streamdev + rpihddevice

2014-12-20 Thread VDR User
 Hi, just curious as I have a Rasp running Openelec and xbmc.

 What advantages does this software have over the stuff I am using?

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

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


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

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

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

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

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


Re: [vdr] Forced boot once a day

2014-09-14 Thread VDR User
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

2014-09-14 Thread VDR User
 Why don't you just use a cron job for this?

 Why to use cron if the ACPI wakeup addon has a setting for this?

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

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


Re: [vdr] Raspberry Pi, Streamdev + rpihddevice

2014-07-15 Thread VDR User
 New problem though, with 1080i atsc, I'm getting screen blanking every 20 
 seconds or so.  It's fine with 480i with the deinterlacer enabled (as per 
 the log).  720p also works fine with deinterlacer disabled.  I can't find 
 anything in the log files that might help with troubleshooting this problem.

 There's a HDMI boost option in config.txt you might want to try:

 # Config HDMI Boost
 # Configures the signal strength of the HDMI interface. Default is 0. Try 4 if
 # you have interference issues (or blanking or no display) with hdmi.
 config_hdmi_boost=4   #Set to change signal strength (0 - 7)

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

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


Re: [vdr] Raspberry Pi, Streamdev + rpihddevice

2014-07-08 Thread VDR User
 I am still struggling howto get accelerated video playback going. Now the A20 
 uses 70% CPU to playback a SD stream. I will look into using the android 
 driver with a linux wrapper around it. It should be doable, somebody on this 
 list reported success (but I didn't ask him for a howto)

 The board can be clocked from 90MHz .. 1GHz. I have yet to measure the power 
 consumption, but the chip gets quite hot (about 80 degrees) when running at 
 1GHz continuously without heat sink.


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

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


Re: [vdr] vdr on allwinner A20

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

On Sat, Jun 14, 2014 at 6:43 AM, cedric.dew...@telfort.nl
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

2014-06-13 Thread VDR User
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

2014-06-03 Thread VDR User
 Thank you for your suggestion, TBS6285 is not supported yet.
 It has si2168 demodulator and si2158 tuner, both are used by another USB
 card.

 I had started to implement it and  found it difficult to me.
 Demodulator code is little bit different and  missing functions there.

 This is sad, because card looks like good, low power consumption, low
 profile, 4x tuner.

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

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


Re: [vdr] converting ts to mkv

2014-05-25 Thread VDR User
You can merge them directly with the mkv container using append. All
you need is the free mkvmerge tool.

On Sun, May 25, 2014 at 7:20 AM, jacek burghardt
jaceksburgha...@gmail.com wrote:
 I had recording setup last night and now I have 111 ts files. I guess heavy
 rain  may caused so many ts files. is there a script that would merge them
 into one ts and convert them into mkv ? How I can setup after recording
 rules to convert recordings ?


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


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


Re: [vdr] converting ts to mkv

2014-05-25 Thread VDR User
I already told you:

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

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


On Sun, May 25, 2014 at 3:36 PM, jacek burghardt
jaceksburgha...@gmail.com wrote:
 I had delete the movie files that had been broken up so badly, but I had few
 recordings that have two files in them. So is it better to convert each ts
 to mkv and merge the mkv ? I set my max recording option tp 30GB.
 I had found an issue with my vdr it crashes when recording tv. i

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


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


Re: [vdr] converting ts to mkv

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

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


Re: [vdr] vdr file system

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

On Sun, May 25, 2014 at 6:32 PM, jacek burghardt
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

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

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

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

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

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


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

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

On Sat, May 24, 2014 at 8:12 AM, Jose Alberto Reguero
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

2014-04-17 Thread VDR User
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

2014-04-09 Thread VDR User
 Here a little feature request:

 Problem: the children are watching a recording, and at the end VDR
 switches to normal live TV, that can be anything. I have to be there at
 the right moment to turn off the screen and the sound, in order to bring
 them to leave the tv-room.

 I would be nice, if VDR could turn off the sound at the end of a replay
 and show a still image (e.g. Children, go to bed now!).

 What do you think about that?

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

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


Re: [vdr] skipping 5/10 seconds

2014-04-07 Thread VDR User
 Well, that's something we can talk about. You could make it so that during
 replay the Left and Right keys perform 5s skips, and the FastForward/-Rewind
 keys (if present on the user's remote control) still retain their normal
 function.

 This kind of behavior sounds like a good compromise and no new keys
 are needed.

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

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


Re: [vdr] skipping 5/10 seconds

2014-04-06 Thread VDR User
 What I would be willing to accept is a patch that makes the skip delta of
 the yellow and green keys (currently a fixed +/-60s) configurable.

 Yes, that's fine. But what's the problem with a second skip-value for
 buttons 1 and 3?

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

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


Re: [vdr] integrating jumpplay-patch

2014-03-31 Thread VDR User
 Why is the last mark not correct?

 hehe, ask noad ;)

.
 What about a setup-parameter jumpplay-dont-stop-on-last-mark?

 I prefer a parameter to disable the end on the last mark.

 And what do you bet, that Klaus will agree to such a
 specialworkaroundforwrongmarkfromnoadparameter...? ;)

That's a suckers bet. ;)

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

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


Re: [vdr] integrating jumpplay-patch

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

 why not just add a parameter stop recording
 on last mark yes/no?

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

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


Re: [vdr] EPG for BBC TV channels?

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

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


Re: [vdr] EPG for BBC TV channels?

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

 I think concensus is that the patch's code is cleaner than the plugin's.
 I looked at the plugin code to see if I could work out how to make the
 Huffman decoding work on standard PIDs for Freeview as well as on
 Freesat's non-standard ones, and found it too difficult to follow. The
 original author might not have so much difficulty, but there's also
 quite a big memory leak which somehow defied my efforts to trace it with
 valgrind.

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

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

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


Re: [vdr] EPG for BBC TV channels?

2014-03-09 Thread VDR User
 Freesat uses a Huffman encoding for EGP data, which has not made its
 way into VDR core.

 a) Plugin EEPG has these tables (and covers some other EPGs as well)
 b) A Freesat patch extends VDR to just the Freesat code tables.

 The patch also covers Freeview HD (which uses the same encoding as
 Freesat, but with standard PIDs instead of Freesat's custom ones), which
 EEPG doesn't, unless it's been updated since I last used it.

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

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


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

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

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

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


Re: [vdr] Streaming DVD contents from VDR?

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

On Sat, Feb 1, 2014 at 12:42 PM, Marko Mäkelä 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

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

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


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

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

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

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


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

2013-12-25 Thread VDR User
If you haven't done so already, please bring this to Johns (author of
softhddevice) at the vdrportal forum.


Thanks

On Wed, Dec 25, 2013 at 6:50 AM, Marko Mäkelä 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

2013-12-25 Thread VDR User
Oops! I misread softdevice as softhddevice. Sorry for the confusion there.

On Wed, Dec 25, 2013 at 1:17 PM, Marko Mäkelä 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

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

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

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


Re: [vdr] [Announce] streamdev-0.6.1

2013-11-30 Thread VDR User
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

2013-11-17 Thread VDR User
You can also just buy a really cheap VDPAU capable Nvidia video card.
For about $25 you can have full HD support using VDPAU hardware
decoding.

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


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

2013-11-07 Thread VDR User
 To me, dumping files all over the drives is messy, sloppy, and bad
 practice. Always has been and always will be. Someone just wants to copy
 MS stupidity into linux.

 I think some features from the FHS predate Windows and even Microsoft.
 Having every file belonging to an application in the same place is
 insecure and makes it more difficult to support things like multiple
 users or one user with multiple PCs, especially if some of them are thin
 clients.

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

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


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

2013-11-04 Thread VDR User
 Hi,
 Have a look to Make.config.template if you want to use vdr 2.x like 1.6
 running in one single dir!

 Yeah, I saw that sort of thing is doable but it's probably worth my
 while doing things properly to fit in with the current way of
 thinking.

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

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

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


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

2013-11-03 Thread VDR User
Have you tried softhddevice for output?
http://projects.vdr-developer.org/git/vdr-plugin-softhddevice.git/

On Sun, Nov 3, 2013 at 2:42 PM, Marko Mäkelä 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

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

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

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

On Sun, Oct 27, 2013 at 8:12 AM, Sergio Daniel Gomez
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

2013-10-12 Thread VDR User
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

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


On Tue, Aug 27, 2013 at 9:51 AM, Stefan Schallenberg 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...

2013-08-21 Thread VDR User
On Wed, Aug 21, 2013 at 2:40 AM, cedric.dew...@telfort.nl 
cedric.dew...@telfort.nl wrote:

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


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

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


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


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

2013-08-20 Thread VDR User
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

2013-08-20 Thread VDR User
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
 

Re: [vdr] Is there somewhere a SETUP/INSTALL doc for VDR ?

2013-08-13 Thread VDR User
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

2013-05-30 Thread VDR User
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?

2013-04-22 Thread VDR User
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


  1   2   3   4   5   6   7   8   >