Re: [vdr] cppcheck: VDR 1.7.18: [timers.c:53]: (error) snprintf size is out of bounds

[Gerald Dachs]

Am Wed, 15 Jun 2011 18:34:59 +0200
schrieb Klaus Schmidinger :

> ...this should be
> 
>sizeof(file) - 1
> 
> Thanks for the bug report.

This is no bug. The size parameter includes the '\0' byte.

Gerald

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

Re: [vdr] will VDR run on this?

[Gerald Dachs]

> http://www.geek.com/articles/chips/raspberry-pi-25-pc-goes-into-alpha-production-20110728/
>
> Any thoughts?

VDR runs just fine on a seagate dockstar, so I see no reason why it
shouldn't run on this device, but I don't believe that it has enough power
show the TV signal via hdmi.

Gerald


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

Re: [vdr] UK FreeviewHD and VDR

[Gerald Dachs]

> If that's not doable, I guess I'll build a new Ion-based box and use xine
> for output. The problem then is that you don't tend to get many PCI slots
> for DVB cards (well, not with the small Atom boards). Maybe I could just
> keep the current vdr box (2.66 MHz P4) and stick an Nvidia graphics card
> in it. Decisions decisions...

Let your DVB-Cards in your vdr box and stream to the Ion box either by
using a vdr instance on both boxes and use streamdev between them, or
having only a vdr instance on the ion box and use vtuner to stream
directly from the DVB cards on the vdr box to the ion box.

Currently I am testing vtuner on a Seagate Dockstar with 2 sundtek DVB-C
USB sticks that is streaming to a Zotac HD-ID 40. It is promising.

Gerald


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

Re: [vdr] UK FreeviewHD and VDR

[Gerald Dachs]

> On 12 August 2011 12:33, Gerald Dachs  wrote:
>> Currently I am testing vtuner on a Seagate Dockstar with 2 sundtek
DVB-C USB sticks that is streaming to a Zotac HD-ID 40. It is
promising.
>
> FYI vtuner is available here http://code.google.com/p/vtuner/

And here for Ubuntu Natty
  https://launchpad.net/~yavdr/+archive/unstable-vdr/

And in this dockstar repository:
  deb http://dockstar.yavdr.org unstable/
  deb-src http://dockstar.yavdr.org unstable/

Currently I am working here on a version that uses memory mapping between
client and kernel module that needs much less cpu:
  https://github.com/gdachs/vtuner.

I want to simplify the client even more but I am not ready.

Gerald






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

Re: [vdr] LiveBuffer for vdr 1.7.x

[Gerald Dachs]

> And no, this patch is not from Gerald D. as the header of the patch 
might imply ;) regards, Tim


It is true that the code in the original patch is not made by me, but 
the patch is made by me, because I had to manipulate the original patch 
so that it fits to the changes the yaVDR-Team made to the vdr.

This is why my name is shown there.

If a patch author wants to be mentioned, I would apply to them to not 
only patch the code, but to add a line with their name to the changelog 
file too.


Gerald


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

Re: [vdr] SoftHDDevice

[Gerald Dachs]

Don't worry just post in english, you'll get the answer also in english. Or
feel free to open a new one in english, you will get answers in english ...
;-)


Thanks, I just send him a private message providing a link to this
thread and asked that he read it when he has a few free minutes so I
don't have to copy&paste.


He told already in the vdr-portal that he wouldn't like to subscribe to 
this list. Generally it might be better if you would have a little bit 
more work doing cut&paste than the plugin author, because he is very 
busy working on the plugin.


Gerald

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

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

[Gerald Dachs]

Am 2012-03-02 00:18, schrieb Tony Houghton:

Going off on a tangent, there's been some discussion about "Pause and
rewind live TV". That could be implemented fairly easily in clients 
with

a big RAM buffer, without adding any complexity to the server.


Big RAM buffer means long breaks between channel changes.

Gerald


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

Re: [vdr] Memory leak (was Re: Channel 4 HD on Freesat)

[Gerald Dachs]

Am 2012-03-26 16:44, schrieb Tony Houghton:

I was probably still
running it when I thought I was testing without a few months ago,
because I didn't realise the debian init script/loader now 
automatically

loads all installed plugins, not just the ones in order.conf.


I am not aware that this ever has been the case. Must be more than 5 
years ago then.


Gerald

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

Re: [vdr] VDR form packages

[Gerald Dachs]

Am 2012-05-08 14:16, schrieb Marx:

Hello
I use Debian for years and to keep it clean I'm trying to use all
software from packages. It generally works, hovewer I have problem
with VDR, XBMC and drivers.
Usually to have the newest driver I need to use some unstable version
of VDR with the newest possible kernel.
VDR in Debian is an option, hovewer it's usually behind the newest
VDR, and number of plugins in repository is low.
This lead to alternative repositories. I know two valuable: e-tobi
and yavdr. I was using e-tobi but it lately isn't updated to the
newest VDR. Yavdr is built on top of Ubuntu, and while it generally
works on Debian, it's not recommended (some things doesn't work).
So there is an option to build packages myself - really no option,
because I have to make package manually for every plugin and for 
every

new version of VDR.
Any idea?


Any idea to what? Your have not asked any questions. What do you want 
to know?


Gerald

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

Re: [vdr] VDR form packages

[Gerald Dachs]

Am 12.05.2012 17:32, schrieb VDR User:

On Sat, May 12, 2012 at 7:47 AM, abang  wrote:

I just noticed, that the missing plugins for squeeze are already in Tobi's
VDR repository. Sorry for the confusion!

But I can't upgrade:

The following packages have unmet dependencies:
  vdr-plugin-chanorg: Depends: vdr-abi-1.7.23-multipatch which is a virtual
package.
  vdr-plugin-burn: Depends: vdr-abi-1.7.23-multipatch which is a virtual
package.
  vdr-plugin-imonlcd: Depends: vdr-abi-1.7.23-multipatch which is a virtual
package.

Any ideas?


Do all those plugins _actually_ depend on that patch? I can't imagine
they do. Just remove the dependency. If they work, the debian/control
file needs to be fixed so the needless dependency is removed.


Ist is not a patch. It is the name of the ABI version. Debian packages 
are using this ABI version to prevent that vdr and vdr plugins with 
different ABIs get mixed up.


The error message means, the mentioned plugins do not belong to the vdr 
that abang is using.


Gerald

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

Re: [vdr] VDR tuning

[Gerald Dachs]

Am 2012-06-11 00:48, schrieb Marx:

Now there is question: how should I define my channels? Some time ago
there was website with channels.conf for many positions but now it
doesn't work. I did search now and found
http://channelpedia.yavdr.com/gen/DVB-S/S13E/ which seems very
interesting.
Some people suggest that it's better to scan channels ourselves.


Why?

Gerald

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

Re: [vdr] Please share your systemd (Upstart) service file

[Gerald Dachs]

Am 28.06.2012 09:01, schrieb Ludwig Nussel:

Manuel Reimer wrote:

Ludwig Nussel wrote:

Yes. Not only for better systemd integration but in general it would be
better if vdr could work without requiring any external scripting or
configuration.


You need some external script to call VDR as somewhere it is required
to configure plugins and plugin parameters and many more stuff, VDR
gets via command line options.


That's the current state. I can't think of a good reason why it has to
stay that way though. VDR itself could have a menu that allows to enable,
disable and configure plugins.


I can't see a benefit of this approach. At least for distributors it 
would get more complicated to install plugins with a specific default 
configuration, because that would mean all configuration informations 
would go into the setup.conf and it is no good idea to manipulate this 
file from outside.


I would like to see the first user of this idea to try to disable a 
plugin that prevents the start of the vdr because of binary 
incompatibility. Must be funny.


Gerald

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

Re: [vdr] emergency restart is too fast for my USB DVB-T receiver

[Gerald Dachs]

Am 28.10.2012 20:50, schrieb cedric.dew...@telfort.nl:

Hi All,
The problem is that the kernel does not reinitialize the receiver until nobody
is using the device. reinitialize takes a few seconds, but vdr does not release
the device long enough for that to happen. The result is that vdr restarts
many times.


The dynamite plugin should handle this for you.

Gerald


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

Re: [vdr] vdr-1.7.32 plugin dvbhddevice fails

[Gerald Dachs]

Am 19.11.2012 05:27, schrieb Richard Scobie:
I have just upgraded from vdr-1.7.31 to vdr-1.7.32 with S2-6400 and 
on

making plugins, I receive the following error:

make[2]: Entering directory
`/home/rs/vdr-1.7.32/PLUGINS/src/dvbhddevice/libhdffcmd'
gcc -O3 -Wall  -fPIC -shared -o libhdffcmd-0.1.0.so bitbuffer.o
hdffcmd_av.o hdffcmd_base.o hdffcmd_generic.o hdffcmd_hdmi.o
hdffcmd_mux.o hdffcmd_osd.o hdffcmd_remote.o
/usr/bin/ld: bitbuffer.o: relocation R_X86_64_PC32 against undefined
symbol `memset@@GLIBC_2.2.5' can not be used when making a shared
object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: *** [libhdffcmd-0.1.0.so] Error 1

As "-fPIC" is being used, I am not sure how to handle the comment,
"recompile with -fPIC"


The error message asks for compile with -fPIC, but the command you show 
is the link, not the compile command.


Gerald



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

Re: [vdr] vdr-1.7.32 plugin dvbhddevice fails

[Gerald Dachs]

Am 2012-11-20 04:38, schrieb Richard Scobie:

Hi Klaus,

Klaus Schmidinger wrote:

Maybe this was caused by the change I introduced in order to be able 
to
easily build a 32-bit version of VDR (and all its plugins) on a 
64-bit

machine:


--- PLUGINS/src/dvbhddevice/libhdffcmd/Makefile 2012/01/18 12:25:20  
  1.2
+++ PLUGINS/src/dvbhddevice/libhdffcmd/Makefile 2012/10/09 09:54:26  
  1.3

@@ -24,6 +24,18 @@
 AR  ?= ar
 ARFLAGS ?= r
+### The directory environment:
+
+VDRDIR ?= ../../../..
+
+### Make sure that necessary options are included:
+
+include $(VDRDIR)/Make.global
+
+### Allow user defined options to overwrite defaults:
+
+-include $(VDRDIR)/Make.config
+
 ### Implicit rules:
%.o: %.c



However, I got no such error message here, and I do use a TT 
S2-6400.

Maybe check your Make.global and/or Make.config files.



I checked both and they seem OK. My previous post just showed the
linking stage. Here is the full output from compiling the dvbhddevice
plugin and "-fPIC" is present during compilation of all object files.


Plugin dvbhddevice:
make[1]: Entering directory 
`/home/rs/vdr-1.7.32/PLUGINS/src/dvbhddevice'
make[1]: Leaving directory 
`/home/rs/vdr-1.7.32/PLUGINS/src/dvbhddevice'
make[1]: Entering directory 
`/home/rs/vdr-1.7.32/PLUGINS/src/dvbhddevice'

g++ -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -c
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"'
-I/mnt/storage/media_build_experimental/linux/include
-I../../../include dvbhddevice.c
g++ -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -c
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"'
-I/mnt/storage/media_build_experimental/linux/include
-I../../../include dvbhdffdevice.c
g++ -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -c
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"'
-I/mnt/storage/media_build_experimental/linux/include
-I../../../include hdffcmd.c
g++ -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -c
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"'
-I/mnt/storage/media_build_experimental/linux/include
-I../../../include hdffosd.c
hdffosd.c: In member function ‘virtual void cHdffOsd::DrawText(int,
int, const char*, tColor, tColor, const cFont*, int, int, int)’:
hdffosd.c:258:9: warning: variable ‘limit’ set but not used
[-Wunused-but-set-variable]
g++ -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -c
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"'
-I/mnt/storage/media_build_experimental/linux/include
-I../../../include menu.c
g++ -O3 -Wall -Werror=overloaded-virtual -Wno-parentheses -fPIC -c
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_GNU_SOURCE -DPLUGIN_NAME_I18N='"dvbhddevice"'
-I/mnt/storage/media_build_experimental/linux/include
-I../../../include setup.c
make -C libhdffcmd all
make[2]: Entering directory
`/home/rs/vdr-1.7.32/PLUGINS/src/dvbhddevice/libhdffcmd'
gcc -O3 -Wall  -fPIC -shared -o libhdffcmd-0.1.0.so bitbuffer.o
hdffcmd_av.o hdffcmd_base.o hdffcmd_generic.o hdffcmd_hdmi.o
hdffcmd_mux.o hdffcmd_osd.o hdffcmd_remote.o
/usr/bin/ld: bitbuffer.o: relocation R_X86_64_PC32 against undefined
symbol `memset@@GLIBC_2.2.5' can not be used when making a shared
object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: *** [libhdffcmd-0.1.0.so] Error 1
make[2]: Leaving directory
`/home/rs/vdr-1.7.32/PLUGINS/src/dvbhddevice/libhdffcmd'
make[1]: *** [libvdr-dvbhddevice.so] Error 2
make[1]: Leaving directory 
`/home/rs/vdr-1.7.32/PLUGINS/src/dvbhddevice'


The machine is running Fedora 16 64bit and gcc version 4.6.2 20111027
(Red Hat 4.6.2-1) and I have no problem building vdr-1.7.31.


If you would take a deeper look into your post you would have noticed 
that the mentioned file bitbuffer.o is not
build to this time. It must have been build in a former stage. So there 
is still no proof that it

has been build with -fPIC.

Gerald

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

Re: [vdr] get a segmentation fault when starting vdr (backtrace included)

[Gerald Dachs]

Am 2012-11-30 10:17, schrieb Lars Hanisch:

 Looks like the pointer returned by sscanf is not valid:

32: bool tComponent::FromString(const char *s)
33: {
34:   unsigned int Stream, Type;
35:   int n = sscanf(s, "%X %02X %7s %a[^\n]", &Stream, &Type,
language, &description); // 7 = MAXLANGCODE2 - 1
36:   if (n != 4 || isempty(description)) {
37:  free(description);
38:  description = NULL;
39:  }
40:   stream = Stream;
41:   type = Type;
42:   return n >= 3;
43: }


From man sscanf:

   The GNU C library supports a nonstandard extension that causes 
the library to
   dynamically allocate a string of sufficient size for input 
strings for the %s

   and %a[range] conversion specifiers.

This is the reason why it doesn't work with ulibc.

Gerald


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

Re: [vdr] Betr: Re: xineliboutput reports "no signal" when started on a paused playback

[Gerald Dachs]

Am 09.12.2012 10:14, schrieb cedric.dew...@telfort.nl:

I agree this behavior is normal and technically correct. I think its a bit
confusing, because when I see no signal, i think there's something wrong
with the receiving hardware, like crashed DVB-t receivers, loose antenna
and so on.

Xineliboutput is aware the stream is paused. Therefore I can think of 2 
solutions:
1)Display a screen that says "Paused" instead of "No signal"

And how shall xineliboutput notice the difference?

2)Unpause, and then re-pause the stream, just long enough to let VDR send
an image.

Xineliboutput didn't pause the stream, so it is not the job of 
xineliboutput to "unpause" the stream.


Gerald

!DSPAM:50c46e6f187481547110970!


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

Re: [vdr] Special Character problems

[Gerald Dachs]

Am 17.12.2012 20:35, schrieb Brian-Imap:

Hi,
I did an apt-get update at the weekend on my Ubuntu with VDR 1.7.33
system. Now the special characters in the recording menu in front of
the channel number are incorrect. Other text and epg data seems to be
OK. I am using UTF-8


It depends on the used version of Ubuntu and the used PPA for the vdr. 
At least Ubuntu 12.04 has no vdr 1.7.33.


Gerald

!DSPAM:50cf8014266161366175190!


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

Re: [vdr] Reserve device for Live-Tv

[Gerald Dachs]

Am 19.12.2012 10:30, schrieb brian_dorl...@t-online.de:

Hi,
might be simple. From ct. If you are using DVB-S, install a FF DVB-C card. That 
is the primary device.
But it cannot record, so recordings are done on all other DVB-S devices.
And how can he use this DVB-C-Device then for Live-TV? He can only view 
the signal from one of the DVB-S-Devices that are locked to the 
transponder they are recording. Additionally for streamdev it is totally 
useless.


Gerald

!DSPAM:50d19286143496329019569!


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

Re: [vdr] Reserve device for Live-Tv

[Gerald Dachs]

Am 19.12.2012 15:11, schrieb Brian-Imap:

On 19.12.2012 11:10, Gerald Dachs wrote:

Am 19.12.2012 10:30, schrieb brian_dorl...@t-online.de:

Hi,
might be simple. From ct. If you are using DVB-S, install a FF DVB-C
card. That is the primary device.
But it cannot record, so recordings are done on all other DVB-S 
devices.

And how can he use this DVB-C-Device then for Live-TV? He can only view
the signal from one of the DVB-S-Devices that are locked to the
transponder they are recording. Additionally for streamdev it is totally
useless.

Gerald




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


Hi,
I haven't tested this yet. But this solution was the one favoured by 
CT to solve the problem of the FF cards not having enough bandwidth to 
handle live viewing and recording at the same time.


The DVB-C FF card will never record in a DVB-S system. I assumed that 
you could view live TV via transfer mode from a DVB-S card.
You didn't understand the problem. If this used DVB-S-Card will be 
needed by an recording it will again switch away from the live channel. 
And again, to use a FF-Card will not help with streamdev.


Gerald

!DSPAM:50d1f3b2162182740914572!


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

Re: [vdr] Reserve device for Live-Tv

[Gerald Dachs]

Am 19.12.2012 16:51, schrieb VDR User:

I ran into the same problem. My solution was to add another dvb card.
When I hit that wall again, I added another. This is the easiest fix
imo and doesn't require any patching. :)


This is always the way to go.

Gerald

!DSPAM:50d1f3d8162281845871878!


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

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Gerald Dachs]

Am 27.12.2012 19:11, schrieb Helmut Auer:
I'm just glad Linux distribution managers don't build cars - 
otherwise we would most

likely be long dead before we find the brake pedal... ;-)


As a distribution manger I have to disagree ;)
All I'm doing now, is to wait til you find a solution which won't be 
changed within the next five days and then I put my distribution 
around it ;)

Something similar I wrote in the portal. So Full ACK.

Gerald

!DSPAM:50dc90eb87784772790529!


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

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Gerald Dachs]

Am 27.12.2012 22:21, schrieb VDR User:

On Thu, Dec 27, 2012 at 10:20 AM, fnu  wrote:


But don't forget, you don't make a solution liek VDR a success or BBS like
vdr-portal only with a few "make; make install" users. Over 95% of VDR users
are using a distribution.

I completely disagree with you claiming "over 95% of VDR users are
using a distribution". Most of the users I talk to regularly, or
observe in various forums do not use pre-made distributions, they
compile VDR themselves so they have full control over what patches (if
any) are being applied, how it's set up, etc.
I would never come to the idea to say that over 95% of the VDR users use 
a distribution and I even would not say the opposite, because I really 
have no idea.


But what makes you so sure that it is wrong? Do you think you know more 
than 5% of all VDR users?


Gerald

!DSPAM:50dccbaa99813830873357!


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

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Gerald Dachs]

One last question:

Am 27.12.2012 22:21, schrieb VDR User:
And of those users, most don't even install VDR, they simply run it 
from the source dir. 
So, real VDR user don't need the install Target in the makefile and 
distributors, at least me,  don't need it too. It seems there must be 
another group of VDR users there that need that stuff. How large might 
be this group?


Gerald

!DSPAM:50dcce26100191898546622!


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

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Gerald Dachs]

Am 28.12.2012 16:38, schrieb Klaus Schmidinger:

So should we go back to the Makefiles of version 1.7.33 and declare this
area of the program source "untouchable" forever?

+1

Gerald

!DSPAM:50ddc50a174441059718148!


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

Re: [vdr] [DISCUSSION REQUEST] reintroduce a common make configuration file in VDR-1.7.35

[Gerald Dachs]

Am 30.12.2012 01:08, schrieb Christopher Reimer:
I don't consider the mailinglist as "central spot of developement". 
Here I'm forced to speak English. Almost all VDR Users are German. And 
in VDR-Portal I reach the critical mass. With the addition that I am 
allowed to speak my native language.
What makes you believe that? Do you have any numbers? I don't have user 
counts either.


I know that visitors of yavdr.org are not the same as vdr users, but 
they might be somehow related. Our statistics shows that the german 
group is with %67 of course the biggest, but far away from "almost all".


Gerald

!DSPAM:50e02a13296741317615234!


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

Re: [vdr] bug in channels.conf.terr?

[Gerald Dachs]

Am 2013-02-11 12:40, schrieb Klaus Schmidinger:

On 11.02.2013 05:04, VDR User wrote:

On Sun, Feb 10, 2013 at 1:32 PM, Klaus Schmidinger
 wrote:

Maybe I should completely remove all channels.conf* files from the
source archive? The existing ones are already rather old, and I 
can't

possibly keep them up to date, anyway.


If they're not going to be kept up-to-date then they don't really
serve any purpose since an outdated channels.conf is useless. People
will just have to channel scan themselves anyways so why bother
keeping outdated files in the source? I see no harm in removing 
them.


On second thought, I guess I won't touch that area at this time, so
close to version 2.0. I'll drop these files after version 2.0, once
automatic transponder scanning will be implemented.


In this case it would be a good idea to delete this line Lars mentioned 
from channel.conf.terr that lets the vdr crash.


Gerald

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

Re: [vdr] bug in channels.conf.terr?

[Gerald Dachs]

Am 2013-02-15 08:49, schrieb Marx:

What I would like to have is scraper for KingOfSat which is probably
most up-to-date sat channels database. I would prefer to filter this
database by provider, sat name etc and produce channels.conf based on
it. There would be need to keep some preferences, like list of FTA
channels, sorting etc but that way making fresh channels.conf would 
be

fast, easy, and productive.


Sounds interesting, go for it.

Gerald

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

Re: [vdr] HD Test clip(s)

[Gerald Dachs]

Am 16.02.2013 17:14, schrieb VDR User:
If you want the highest quality deinterlacing on 1080i, a GT220 is 
required.
A GT610 is good enough, costs only the half and it is much easier to 
cool it quietly.


Gerald

!DSPAM:511fb59841991258417478!


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

Re: [vdr] HD Test clip(s)

[Gerald Dachs]

Am 16.02.2013 21:28, schrieb VDR User:

On Sat, Feb 16, 2013 at 8:36 AM, Gerald Dachs  wrote:

If you want the highest quality deinterlacing on 1080i, a GT220 is
required.

A GT610 is good enough, costs only the half and it is much easier to cool it
quietly.

I've read the opposite -- that the GT610 struggle with 1080i highest
deinterlacing.

I don't have to read about it, I own one. I know it better.

And I am not the only one that thinks like this. It is common sense in 
the vdr-portal.de that the GT610 is good enough for temporal-spatial.


Gerald

!DSPAM:51200d5c44881319480443!


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

Re: [vdr] Call for development: enhancing mplayer-plugin

[Gerald Dachs]

Am 2013-02-27 11:56, schrieb Peter Münster:

Hi,

Support for seeing the VDR osd over mplayer doesn't exist yet.

Who could add this feature please? And what would be the price?


I think this is already work in progress: 
http://www.vdr-portal.de/board17-developer/board21-vdr-plugins/p1127401-play-git-up-to-date/?highlight=%5Bplay%5D#post1127401


Gerald

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

Re: [vdr] Audio only output device?

[Gerald Dachs]

Am 13.03.2013 15:09, schrieb Füley István:

Subcribe.


To what?

Gerald

!DSPAM:5140aac1168913192934288!


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

Re: [vdr] New Makefile system

[Gerald Dachs]

Am 24.03.2013 15:48, schrieb VDR User:

On Sun, Mar 24, 2013 at 5:24 AM, Helmut Auer  wrote:

Which plugin are you refering to?


softhddevice and live Plugin.
There was a mismatch between c an c++ flags and this was surely caused by
the new makefile system :)

When using the new style Makefile supplied with softhddevice git, I
was getting crashed. Johns acknowledged the plugin had issues with the
new Makefile and recommended to continue using the provided old-style
Makefile. So are you saying that you've actually fixed softhddevice so
it works correctly and no longer crashes when using the new-style
Makefile? If so, would you mind submitting that patch to Johns so he
can merge it?
I don't know whether Tobi started his plugin from scratch, or used our 
yavdr package as template, but we don't have crashes either. With vdr 
1.7.41 and 1.7.42 and softhddevice 0.6.0 there are no Problems at least 
with vdpau on 64 bit systems. The only used patch (attached) has nothing 
to do with the new makefiles.


Gerald


!DSPAM:514f1e83250661305017642!
Index: vdr-plugin-softhddevice-0.5.2.git.20130303.1729/Makefile
===
--- vdr-plugin-softhddevice-0.5.2.git.20130303.1729.orig/Makefile   
2013-03-11 16:32:00.0 +0100
+++ vdr-plugin-softhddevice-0.5.2.git.20130303.1729/Makefile2013-03-12 
11:40:16.893647421 +0100
@@ -32,8 +32,8 @@
 #CONFIG += -DHAVE_PTHREAD_NAME # supports new pthread_setname_np
 #CONFIG += -DNO_TS_AUDIO   # disable ts audio parser
 #CONFIG += -DUSE_TS_VIDEO  # build new ts video parser
-#CONFIG += -DUSE_MPEG_COMPLETE # support only complete mpeg packets
-#CONFIG += -DUSE_VDR_SPU   # use VDR SPU decoder.
+CONFIG += -DUSE_MPEG_COMPLETE  # support only complete mpeg packets
+CONFIG += -DUSE_VDR_SPU# use VDR SPU decoder.
 
 ifeq ($(ALSA),1)
 CONFIG += -DUSE_ALSA
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] DNS-323 NAS with 64MB ram, can this run VDR?

[Gerald Dachs]

Am 2013-11-18 15:26, schrieb cedric.dew...@telfort.nl:

Hi All,

I have been given a D-link DNS-323 NAS. This machine runs linux, but
only has 64MB RAM.
I have tested on my x86 machine. VDR uses 28MB RAM while idle, and
this rises to 48MB while decrypting and recording one SD channel.

Is it possible to run VDR on this machine? How can I keep the RAM
usage low?


RAM is not the problem. An ARM CPU with 1.2 GHz ist maxed out 
decrypting one HD stream. I doubt that your CPU has more performance.


Gerald

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

Re: [vdr] aufs instead of mhddfs with vdr 2.1.2

[Gerald Dachs]

Am 01.12.2013 11:24, schrieb Matthias Biel:
> Hi Mike,
>
> If I understand your question correctly, you have several file systems
> for video data and you want to join them for use with VDR.
>
> VDR supports this out of the box: If your video directory ends with
> '0', VDR will automatically look for directories ending with 1, 2, ...
> and will use all of them. So you could mount your filesystems to
> directories that correspond to the naming scheme. You can find a more
> detailed description at:
> http://www.vdr-wiki.de/wiki/index.php/VDR_Optionen
This is true, but the current vdr developer version doesn't support this
anymore. So why not look for new solutions?

Gerald

!DSPAM:529b13a3216559371165570!


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

Re: [vdr] Why use /var/lib/vdr?

[Gerald Dachs]

Am 11.12.2013 18:55, schrieb cedric.dew...@telfort.nl:
> Hi All,
>
> I have build VDR systems based on arch linux and debian. On both, one
> half of the configuration files in is /etc/vdr, the other half in
> /var/lib/vdr.
> Why has the location /var/lib/vdr been choosen for the configuration
> files?
That is not true. Configuration-Files are only in /etc/vdr. What you can
see in /var/lib/vdr are data files.
Configuration files are only modified by root and never by the
application. The files in /var/lib/vdr are modified by the vdr.

Gerald

!DSPAM:52a8b97950221956011510!


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

Re: [vdr] libcec integration

[Gerald Dachs]

Am 22.12.2013 15:06, schrieb Torgeir Veimo:
> Have anyone looked into integrating libcec into VDR, similar to lirc?
I don't think that this is necessary. AFAIK the libcec provides
generation of uinput events. Together with eventlircd it should be
possible to control the vdr.

Gerald

!DSPAM:52b6fb6f86201284335806!


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

Re: [vdr] libcec integration

[Gerald Dachs]

Am 22.12.2013 15:47, schrieb Gerald Dachs:
> Am 22.12.2013 15:06, schrieb Torgeir Veimo:
>> Have anyone looked into integrating libcec into VDR, similar to lirc?
> I don't think that this is necessary. AFAIK the libcec provides
> generation of uinput events. Together with eventlircd it should be
> possible to control the vdr.
>
I wanted to say the libcec-daemon.

Gerald

!DSPAM:52b7082188345275951292!


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

Re: [vdr] libcec integration

[Gerald Dachs]

Am 23.12.2013 12:09, schrieb Torgeir Veimo:
> True, but libcec-daemon is tricky at best, and currently doesn't
> compile (nor run properly after tweaking the source) on raspbian . And
> cec is more than just remote controls, you can turn on and off the tv
> etc. That doesn't work when piped through the remote plugin.
>
I didn't talk about the remote plugin and the extra functionality can be
done with irexec.

Gerald

!DSPAM:52b8387b137254908619775!


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

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

[Gerald Dachs]

Am 05.01.2014 14:40, schrieb Lars Hanisch:
> "I'll do my very best..." :) Lars.
This is funny! English, but only understood by German.

Gerald

!DSPAM:52c9992d302581408685597!


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

Re: [vdr] still image at end of replay

[Gerald Dachs]

Am 2014-04-10 12:52, schrieb Peter Münster:

On Thu, Apr 10 2014, VDR User wrote:


This really sounds like something that should be solved in parenting
and not code.


With code it's easier... ;)


Not for the coder.

Gerald

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

Re: [vdr] converting ts to mkv

[Gerald Dachs]

Am 25.05.2014 16:20, schrieb jacek burghardt:
> 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 ?
>  
Why do you want to do this? You will get a movie with 110 breaks that
last some seconds in it. Throw it away.

Gerald

!DSPAM:5382455b408061556753072!


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

Re: [vdr] converting ts to mkv

[Gerald Dachs]

Am 2014-05-26 05:09, schrieb 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.


This is all true. Beside that there is no need to extract audio before 
using handbrake, there is even no need to use mkvmerge if you don't 
pretend on mkv.
I had used an after recording script that just checked with avprobe, 
whether the video codec is mpeg2video, or h264. If it was mpeg2video I 
simply renamed the file to
.mpeg, and for h264 to .mp4. Every programs known by me played this 
files without any problems. No need for mkv.


To add some ts files to one use cat:  cat 1.tx 2.ts >new.ts

Gerald


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

Re: [vdr] Forced boot once a day

[Gerald Dachs]

Am 14.09.2014 um 12:02 schrieb Thomas Maaß:
> 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.
>
It is not the job of the vdr to do such OS depending actions. Use the
ACPI Wakeup addon for this task like most vdr distributions do.

Gerald

!DSPAM:54156be3490091730197352!


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

Re: [vdr] Forced boot once a day

[Gerald Dachs]

Am 14.09.2014 um 17:07 schrieb 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?

Gerald


!DSPAM:5415b51e652171744718748!


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

Re: [vdr] Forced boot once a day

[Gerald Dachs]

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

Gerald

!DSPAM:5415d62873265520375805!


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

Re: [vdr] plex

[Gerald Dachs]

Am 08.01.2015 um 18:16 schrieb jacek burghardt:
>
> I wonder if anyone is using plex with vdr.? I use vdr 2.1.6 and it
> does not seems to work with vdr i get channel not responding and plex
> plugin shows unavaiable
I don't understand exactly what you mean, because plex is ambiguous.
There is the Plex Media Server, the Plex Apps for smartphones, or TVs,
Plex Home Theater, Plex Web App ...

I use the Plex Media Server, but not directly with the vdr. I use a vdr
recording hook, that transcodes every recording to mp4 with x264 codec
and renames it so that Plex Media Server easy gets it infos from the
themoviedb, and thetvdb. That works very good, at least good enough for me.

I don't use Plex for live TV, my TV can do this alone.

Gerald




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

Re: [vdr] Restart of frontend

[Gerald Dachs]

Am 14.02.2015 um 19:53 schrieb 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?
>
We have no times for this isolated feature of starting X and vdr
parallel, because we do more.
We don't use lircd, but eventlircd, because eventlircd has not to wait
until the remote devices are ready, so the vdr don't need to wait for
them too.
Many current dvb tuners need long time to get ready, sometimes because
usb enumeration happens late, or firmware has to be loaded. For this
Lars has invented the dynamite plugin that collects tuners when they are
ready and gives them to the vdr.
Other distributions have to wait with the vdr start till the last dvb
tuner is ready. We don't wait for any of them. The vdr will show a
picture when the first tuner comes ready. Of course it is very hardware
related, but 10 seconds from bios post till live tv is possible. We had
even some customized setups that did it in 6 seconds.

Gerald



!DSPAM:54dfe318514691998282038!


___
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!

[Gerald Dachs]

Am 19.02.2015 um 11:38 schrieb Klaus Schmidinger:
> VDR version 2.2.0 is now available at

Sorry, no facebook account, so it has to go here:

+1

Gerald

!DSPAM:54e5c696350228714022420!


___
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?

[Gerald Dachs]

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

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

[Gerald Dachs]

Am 19.02.2015 um 19:24 schrieb 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.
>
Don't know about the details. I am using Avidemux for cutting my
recordings as I told and have never seen artefacts. I use Avidemux,
because it is the only editor I have found that does not transcode the
movie if I don't want it.

Gerald

!DSPAM:54e63a3f479529078611732!


___
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?

[Gerald Dachs]

Am 19.02.2015 um 20:32 schrieb Gerald Dachs:
> Am 19.02.2015 um 19:24 schrieb 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.
>>
> Don't know about the details. I am using Avidemux for cutting my
> recordings as I told and have never seen artefacts. I use Avidemux,
> because it is the only editor I have found that does not transcode the
> movie if I don't want it.
>
Ah, I forgot, I always cut on I-frames.

Gerald

!DSPAM:54e63b73480795911313045!


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

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

[Gerald Dachs]

Am 2015-04-14 08:59, schrieb Matthias Wächter:

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.


Gerald

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

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

[Gerald Dachs]

Am 2015-04-15 00:55, schrieb Niedermeier Günter:

Am 14.04.2015 um 09:56 schrieb Gerald Dachs:

Am 2015-04-14 08:59, schrieb Matthias Wächter:

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.


Gerald


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.

Gerald

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

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

[Gerald Dachs]

Am 2015-04-15 16:43, schrieb VDR User:

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

VNSI/XVDR, VDR configuration synchronization hassle with streamdev.

use softhddevice + vdr + streamdev-client on the clients and connect 
to a

streamdev-server on the main vdr.


Well, that works so far, but it is not an effective substitute for 
the

functionality of vdr-sxfe,
at least not for what I use it mainly. All functions run on the 
remote

machine, and only the screen is
transferred to the local machine.


This solution, or the already mentioned possibility with Kodi and 
vnsi/xvdr,

are the only supported ways currently.
If this is not good for you, then start coding.


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


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.

Gerald

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

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

[Gerald Dachs]

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

Gerald

!DSPAM:552e984a166098533532618!


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

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

[Gerald Dachs]

Am 2015-04-15 22:54, schrieb Lars Hanisch:

Am 15.04.2015 um 18:37 schrieb VDR User:

On Wed, Apr 15, 2015 at 8:03 AM, Gerald Dachs  wrote:

Proper server/client has been on the user wishlist for ages. There's
no reason to be rude to someone looking for something better. If 
those

solutions were all that great then there wouldn't be any reason to
ask. Of all the people who are scolded with `code it yourself then`,
how many actually can? Probably very very very few, so why bother 
with

such useless comments?


Nonsense, I have not been rude. I have even some examples where I 
told this

to other users
that started coding afterwords. That made it a very useful comment.

To not say it and miss a change to get it done is useless.


Who, and what have they coded? Project names?


 restfulapi and dynamite are two of them.
 And he encouraged me to start with dbus2vdr.


Restfulapi and dynamite were the projects I had in mind, thanks Lars. 
And restfulapi was a starter for even two more fellows.
And just in case that you will tell now that nobody needs that, then you 
talk only for yourself. Dynamite is used by all yaVDR users.

Restfulapi is now part of OpenELEC.

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


Gerald

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

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

[Gerald Dachs]

Am 2015-04-16 16:09, schrieb VDR User:

What exactly do you think I was wrong about?


You forgot already? You told that I was rude and I proofed that I was 
not.


Gerald


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

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

[Gerald Dachs]

Am 16.04.2015 um 17:09 schrieb VDR User:
> Gerald, my opinion is my opinion - you disagreeing doesn't change
> anything. It's not wrong and nobody is the opinion police.
So why you then argued against my argumentation to show that  I am not
rude and named me even
a liar? And after I proofed that I didn't lie you just continued to let
me me just look stupid?

All the years I had the feeling that you are just a troll, but I hoped
that I was wrong.

Gerald



!DSPAM:552fdaa1645671082260260!


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

Re: [vdr] xineliboutput and streamdev at the same time

[Gerald Dachs]

Am 20.04.2015 um 15:34 schrieb Marko Mäkelä:
> On Mon, Apr 20, 2015 at 03:15:08PM +0200, Patrick Boettcher wrote:
>>> Is it technically possible to for example pause a
>>> live SD TV stream and copy some files over the Ethernet at the same
>>> time?
>>
>> Which scenario? VDR on RPI or on a remote? If VDR on a remote host,
>> IIRC, pausing causes very few bandwidth as only a still image is
>> displayed.
>
> VDR client+server on the same RPi. I guess it is simply too much to
> ask of the poor RPi.
Kodi and vnsi-addon + vdr and vnsi-server-plugin are working on the same
RPi, and it is a much heavier load than your setup. I can't see why this
shouldn't work.

Gerald

!DSPAM:55352184204551113121336!


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

Re: [vdr] [ANNOUNCE] rpihddevice plugin 1.0.0

[Gerald Dachs]

Am 2015-10-19 01:22, schrieb Torgeir Veimo:

Do you know any rpi distro this one will be included in? Don't think
it's included in raspian yet?


MLD: http://www.minidvblinux.de/

Gerald

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

Re: [vdr] Using a rasberry pi as vdr client

[Gerald Dachs]

Am 01.02.2016 um 15:01 schrieb Harald Milz:
> Hi, 
>
> a bit late maybe but vnsiverver on the VDR side and Openelec / kodi on the
> RPi side should be fine, that's what I am using, and the WAF is pretty high. I
> got a Hama MCE remote with USB IR receiver, which worked out of the box. 
>
An IR receiver is usually not necessary. The HDMI-CEC support of the
raspberry pi is very good.
Mostly the remote of the TV is just enough.

Gerald

!DSPAM:56afa1b4373991281062396!


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

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

[Gerald Dachs]

Am 2016-02-09 10:19, schrieb Nicolas Huillard:

Hi all,

My new Raspberry Pi2 install lacks a media player, which begins to be a
bit annoying. The current setup :
* NFS server
* DigitalDevices Octopus Net DVB network server
* VDR + rpihddevice + satip on the Pi2 : live TV, timers, recordings,
etc.


IMHO OpenELEC covers all your needs and is still lightweight.

Gerald

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

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

[Gerald Dachs]

Am 2016-02-09 10:43, schrieb Nicolas Huillard:

Le mardi 09 février 2016 à 10:33 +0100, Gerald Dachs a écrit :

Am 2016-02-09 10:19, schrieb Nicolas Huillard:
> Hi all,
>
> My new Raspberry Pi2 install lacks a media player, which begins to be a
> bit annoying. The current setup :
> * NFS server
> * DigitalDevices Octopus Net DVB network server
> * VDR + rpihddevice + satip on the Pi2 : live TV, timers, recordings,
> etc.

IMHO OpenELEC covers all your needs and is still lightweight.


As I understand OpenELEC, it is a lightweight Kodi (XBMC) distro, which
by definition gets VDR out of the way.


No, that is not true. I even helped to better integrate VDR into 
OpenELEC.


Gerald

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

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

[Gerald Dachs]

Am 2016-02-09 12:01, schrieb Nicolas Huillard:

Le mardi 09 février 2016 à 11:35 +0100, Gerald Dachs a écrit :

Am 2016-02-09 10:43, schrieb Nicolas Huillard:
> Le mardi 09 février 2016 à 10:33 +0100, Gerald Dachs a écrit :
>> Am 2016-02-09 10:19, schrieb Nicolas Huillard:
>> > Hi all,
>> >
>> > My new Raspberry Pi2 install lacks a media player, which begins to be a
>> > bit annoying. The current setup :
>> > * NFS server
>> > * DigitalDevices Octopus Net DVB network server
>> > * VDR + rpihddevice + satip on the Pi2 : live TV, timers, recordings,
>> > etc.
>>
>> IMHO OpenELEC covers all your needs and is still lightweight.
>
> As I understand OpenELEC, it is a lightweight Kodi (XBMC) distro, which
> by definition gets VDR out of the way.

No, that is not true. I even helped to better integrate VDR into
OpenELEC.


I meant that Kodi becomes the main interface, with a VNSI/PVR client
add-on, while the VDR instance will remain (in my case) on the headless
server, with a limited or non-existing UI.


No, OpenELEC supports and provides a local VDR.



Will the current stable Kodi 15.2 include your work ?


yes


Any specific advice on how to have this kind of setup running ?


not really. My work just allows a channel scan from the vdr-addon 
settings instead of using the vnsi client interface to the VDR.


Gerald


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

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

[Gerald Dachs]

Am 09.02.2016 um 17:07 schrieb 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.

Gerald

!DSPAM:56ba1e4b68607589549215!


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

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

[Gerald Dachs]

Am 2016-02-09 22:55, schrieb 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.


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.

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.

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?

Gerald


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

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

[Gerald Dachs]

Am 10.02.2016 um 16:58 schrieb 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
>
> 
>


!DSPAM:56bb82fd484001781562189!


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

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

[Gerald Dachs]

Sorry for the empty answer before.

Am 10.02.2016 um 16:58 schrieb 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..
That is irrelevant, because that can happen with your solution too
>> 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.
I can't see why it is a problem to mention other features he would get
with another solution.

>> 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.
On an RPi? With hardware support? I don't believe that.

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 asked you already before to explain what makes OpenELEC more
complicated, you
didn't answer.
The only thing that is really obvious that you have no idea what you are
talking about.
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.

Gerald


!DSPAM:56bb8663485834103731893!


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

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

[Gerald Dachs]

Am 10.02.2016 um 23:45 schrieb VDR User:
> 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.
Of course not. You told that my solution is too complicated, you have to
prove it. I did not judge about your solution.

> It's really starting to seem teenage girl'ish so maybe you should give
> it a rest.
My fault, I should have learned over the years that you are just a troll.

Gerald

!DSPAM:56bbc3a8493521263344062!


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

Re: [vdr] vdr + xbmc

[Gerald Dachs]

Quoting serge pecher <[EMAIL PROTECTED]>:

>
>>
>>
>> --
>>
>> Message: 3
>> Date: Mon, 1 Dec 2008 17:48:53 +0100 (CET)
>> From: "Niels Wagenaar" [EMAIL PROTECTED]
>> Subject: Re: [vdr] MythTV Adds Support For NVIDIA VDPAU
>> To: "VDR Mailing List" vdr@linuxtv.org
>> Message-ID:
>> [EMAIL PROTECTED]
>> Content-Type: text/plain;charset=iso-8859-1
>>
>> Op Ma, 1 december, 2008 17:31, schreef Magnus Andersson:
>>>
 And from my point of view, MythTV is still not as accesible compared too
 for instance Mediaportal or Microsoft MCE. IMHO, the best combo is still
 VDR for DVB viewing in combination with XBMC for multimedia viewing. But
 then again, this is my oppinion :-)

 Regards,

 Niels Wagenaar

>>>
>>> I agree. Do you have a working script or a good way to switch between
>>> xbmc and vdr? There are a few threads about this at
>>> http://xbmc.org/forum/ but no good solution. I want to use vdr as I use
>>> it today with fast channelswitching and without http connection to
>>> streamdev plugin.
>>>
>>
>> I use VDR in combination with the Reel HDe and XBMC in Xubuntu 8.10. The
>> HDE uses HDMI while XBMC is using the onboard VGA connection. I use two
>> remotes : Hauppauge remote for VDR (/dev/input using Remote plugin) and
>> MCE Remote for XBMC (lirc). Extremely easy to use and to control.
>>
>> If you have a software based output plugin and two remotes, you can use a
>> .lirc in combination with irexec which starts vdr-sxfe or XBMC. I've set
>> this up for a good friend where his MCE Remote has two perticular buttons
>> (LiveTV and DVD) configured for starting two scripts which then starts
>> xine or XBMC. He then uses the MCE Remote (minus the two buttons) for XBMC
>> and his other remote (Hauppauge) with VDR through the Remote plugin and
>> /dev/input location.
>>
>> Oh, and the software based solution has a high WAF according to my friend
> :)

I use one remote for both, I toggle with one button between 3 modes.
mode 1
   vdr-sxfe on Plasma TV and graphttft-fe on TFT in case
mode 2
   xbmc on Plasma TV and graphttft-fe on TFT in case
mode 3
   nothing on Plasma TV and xbmc on TFT in case
I start vdr with --lirc=/dev/null so that it doesn't react on the remote.
Vdr-sxfe ist started with --lirc. Vdr-sxfe is never started the same time
that xmbc is running, so I can use the same remote for both.

Gerald



This message was sent using IMP, the Internet Messaging Program.


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

Re: [vdr] vdr + xbmc

[Gerald Dachs]

Quoting Niels Wagenaar <[EMAIL PROTECTED]>:

> This is indeed something I was looking for. Forgot that some options  
>  are extremely easy to resolve. But I was wondering, what remote do   
> you use yourself and did you configure a .lircrc for vdr-sxfe?

Nothing special, it is a mediacenter Philips remote that came with my
OriginAE case. Later I will use my Harmony 555 that has already learned
the codes from the Philips remote. The case has a remote receiver from
the company irtrans, they provide a lirc compatible server named irserver.

I use a lircrc, but not for vdr-sxfe. Vdr-sxfe doesn't need a lircrc,  
the remote.conf from the vdr is all you need. The lircrc only reacts  
on one unused button on the remote and toggles the modes. It is very  
short. I am not completely
ready with it, I did it yesterday evening only. What is missing is that I
intercept the power button and if vdr-sxfe is currently not seen I  
will switch to tv mode and then send the power button to vdr-sxfe so  
that the vdr has a chance to
say no and I will see the reason why it wouldn't like to power down.

Gerald


This message was sent using IMP, the Internet Messaging Program.


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

Re: [vdr] vdr + xbmc

[Gerald Dachs]

Quoting Magnus Hörlin <[EMAIL PROTECTED]>:

> I have just one remote in my livingroom. Since my LG LCD has an RS232 port I
> can control power and volume on if from my .lircrc and some perl scripts. So
> with the "Start" button on my MCE remote (only good thing Microsoft ever
> made) the TV is powered and vdr-sxfe started. And the power button shuts
> everything down. Very high WAF/KAF. Now I intend to have some other button
> start XBMC instead to see if it's any good.
> /Magnus H

I use the power button for power on and power off. The start/eHome  
button I use for toggling my modes.

That has the highest WAF ;)

Gerald


This message was sent using IMP, the Internet Messaging Program.


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

Re: [vdr] xineliboutput OSD and playback problems

[Gerald Dachs]

Quoting Antti Seppälä <[EMAIL PROTECTED]>:

> You need a compositing window manager to see both the hud osd and
> video at the same time.
>
> I recommend xcompmgr because it can run in parallel to your normal
> window manager and serve the necessary compositing extensions as an
> addition. Of the compositing managers I've tried it also seems to be
> the fastest / least cpu intensive.


After reading your mail I have tried yesterday again to use xcompmgr instead
of compiz for the hud osd without success. The osd doesn't show up. I think
my configuration can't be that wrong, as the hud osd is shown with compiz. Any
hints what I have to look for?

I use xineliboutput 1.0.3 on Intrepid Ibex with the nvidia x11 driver.
My xinitrc contains only calls to nvidia-settings for setting the blanking
interrupts and unclutter to let the mouse cursor disappear beside the
calls to compiz or xcompmgr. Is xcompmgr no replacement for compiz? Does
xcompmgr need something else?

Gerald



This message was sent using IMP, the Internet Messaging Program.


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

Re: [vdr] vdr + xbmc

[Gerald Dachs]

Am Tue, 2 Dec 2008 16:43:55 +0200
schrieb "Alex Betis" <[EMAIL PROTECTED]>:
> 
>  Looks
> like there is a way to stream live TV to XBMC from VDR already. Any
> reason you don't use that option and prefer to have 2 frontends?

For me tv is the main thing, multimedia is a nice add on. Currently
xineliboutput is simply the best frontend for budget only systems.

I had planned to use mms for multimedia, integration of vdr-sxfe is good
documented. XBMC has still to show whether it is a good replacement for
mms and not only an eye candy. With my setup the exchange of frontends
is an easy task.

But maybe the most important reason is that it is so unbelievable
simple, and I am so short of time.

Gerald




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

Re: [vdr] xineliboutput OSD and playback problems

[Gerald Dachs]

Am Tue, 2 Dec 2008 21:11:54 +0200
schrieb "Antti Seppälä" <[EMAIL PROTECTED]>:

> 2008/12/2 Gerald Dachs <[EMAIL PROTECTED]>:
> >
> > After reading your mail I have tried yesterday again to use
> > xcompmgr instead of compiz for the hud osd without success. The osd
> > doesn't show up. I think my configuration can't be that wrong, as
> > the hud osd is shown with compiz. Any hints what I have to look for?
> >
> 
> Do you start the xcompmgr with the -n switch?

Yes

> Does it start correctly?

I didn't find errors in logs, but I wasn't very careful searching. I
could see the process running all the time.

> If I start xcompmgr without client side compositing then I'm unable to
> get hud to work properly.

Not sure what you mean.

> Which window manager you are using together with xcompmgr? Try to make
> sure that you have the Ubuntu desktop effects disabled as they will
> probably interfere with the operation of xcompmgr.

I don't use a windows manager, as I explained already my xinitrc is
nearly empty. There is no Ubuntu desktop installed, no gdm, nothing.
It sounds as if xcompmgr is no drop in replacement for compiz, I need
a windows manager too? And this together will need less resources than
compiz without anything else? I have only three X11 applications
running: vdr-sxfe, graphtft-fe and xbmc/mms. They are all running
fullscreen, I don't need a windows manager. This is why I want to
get rid of compiz.

Gerald


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

Re: [vdr] xineliboutput OSD and playback problems

[Gerald Dachs]

Am Tue, 2 Dec 2008 22:46:04 +0200
schrieb "Antti Seppälä" <[EMAIL PROTECTED]>:
> I run evilwm + xcompmgr, very light weight and suitable
> for HTPCs.
>
> > And this together will need less resources than
> > compiz without anything else?  

> I think there's not much of a difference in your case but I suppose
> you can go and give it a try.

I think I will do, at least it could give me more stability than
with compiz, thanks. Will any windows manager do it? I like 
AntiWM very much.

Gerald

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

Re: [vdr] xineliboutput OSD and playback problems

[Gerald Dachs]

Am Tue, 2 Dec 2008 21:59:10 +0100
schrieb Gerald Dachs <[EMAIL PROTECTED]>:

> Am Tue, 2 Dec 2008 22:46:04 +0200
> schrieb "Antti Seppälä" <[EMAIL PROTECTED]>:
> > I run evilwm + xcompmgr, very light weight and suitable
> > for HTPCs.
> >
> > > And this together will need less resources than
> > > compiz without anything else?  
> 
> > I think there's not much of a difference in your case but I suppose
> > you can go and give it a try.
> 
> I think I will do, at least it could give me more stability than
> with compiz, thanks. Will any windows manager do it? I like 
> AntiWM very much.
> 

I tried it, hud is working, xmbc not :(

Gerald

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

Re: [vdr] Few more questions about xinelibout

[Gerald Dachs]

Quoting Alex Betis <[EMAIL PROTECTED]>:
> I was looking for the right word... tearing...
> I have nVidia 177.82 driver. Again, mplayer has no such problem.

You could try to activate all sync to vblank irqs with nvidia-settings.

Gerald




This message was sent using IMP, the Internet Messaging Program.


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

Re: [vdr] XBMC + VDR 1.7.0

[Gerald Dachs]

Quoting jori.hamalai...@teliasonera.com:

>
>> http://www.youtube.com/watch?v=_Cl70fq7sn8
>> here's you can have a look on xbmc and integrated in it vdr
>
> 1:30 to boot.. :)
>

My own "integration" needs 0:15 :( , but I am working on it.

Gerald


This message was sent using IMP, the Internet Messaging Program.


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

Re: [vdr] New Video Decode and Presentation API from NVidia

[Gerald Dachs]

Am Sun, 14 Dec 2008 16:55:52 +0200
schrieb Lauri Tischler :

> Andrew Herron wrote:
> > Hi,
> > 
> > This ASUS board would be suitable;
> > 
> > http://www.asus.com/products.aspx?modelmenu=1&model=2579&l1=3&l2=11&l3=812&l4=0
> 
> Too small, not enough pci-slots, minimum three pci-slots needed.
> Four or five pci-slots would be nice.

And wrong cpu, I think I will buy this one:
http://www.phoronix.com/scan.php?page=article&item=nvidia_8200_mobos&num=3
If I would need anyway a graphics card, then a big cooler would only
block a pci-e slot. The cpu socket is more near to the back side of the
motherboard than on many other mainboards. So I would get more space
between the cpu cooler and the cd rom drive in my S16T case.

Gerald 

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

Re: [vdr] New Video Decode and Presentation API from NVidia

[Gerald Dachs]

Quoting Torgeir Veimo :

> Some information here;   
> http://www.nvidia.com/docs/CP/11036/PureVideo_Product_Comparison.pdf

Not very helpful, it doesn't contain the mentioned chipsets.

Gerald


This message was sent using IMP, the Internet Messaging Program.


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

Re: [vdr] New Video Decode and Presentation API from NVidia

[Gerald Dachs]

Sorry for the direct mail.

Quoting Chris Silva <2manybi...@gmail.com>:

>> http://www.phoronix.com/scan.php?page=article&item=nvidia_8200_mobos&num=3
>> If I would need anyway a graphics card, then a big cooler would only
>> block a pci-e slot. The cpu socket is more near to the back side of the
>> motherboard than on many other mainboards. So I would get more space
>> between the cpu cooler and the cd rom drive in my S16T case.
>
> But the problem remains. I need at least 3 PCI slots. So, any
> suggestions on other boards with VDPAU *supported* chips?

What makes you so sure that the 8200 chipset is not supported? Of  
course I have read this
http://www.nvnews.net/vbulletin/showthread.php?t=124458, but I have
found this too:  
http://www.phoronix.com/forums/showpost.php?p=53474&postcount=39 .
On other places I could read that the only differences between 8200 and 9300
are the smaller manufacturing process, clock speed and number of shaders.

Here it is even mentioned explicitly  
http://www.nvnews.net/vbulletin/showthread.php?p=1873716

Gerald


This message was sent using IMP, the Internet Messaging Program.


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

Re: [vdr] New Video Decode and Presentation API from NVidia

[Gerald Dachs]

Quoting Pertti Kosunen :

> Gerald Dachs wrote:
>> What makes you so sure that the 8200 chipset is not supported?
>
> It is VDPAU supported, but AFAIK can't decode VC-1.

But what about this post:
http://www.phoronix.com/forums/showpost.php?p=53474&postcount=39
He must be wrong or you.

Does somebody know the gpu that is used by the 8200 chipset? Is it not
G98?

Gerald



This message was sent using IMP, the Internet Messaging Program.


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

Re: [vdr] New Video Decode and Presentation API from NVidia

[Gerald Dachs]

Am Mon, 15 Dec 2008 17:18:51 +0100
schrieb Nicolas Huillard :

> Torgeir Veimo a écrit :
> >> Does somebody know the gpu that is used by the 8200 chipset? Is it
> >> not G98?
> > 
> > Some information here;
> > http://www.nvidia.com/docs/CP/11036/PureVideo_Product_Comparison.pdf
> 
> Is PureVideo the same as VDPAU ?

Definitively not, maybe PureVideo HD, but never PureVideo.
Currently even not all PureVideo HD devices are supported.
as I told already in my other post, this document is not very helpful.

Gerald

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

Re: [vdr] shutdown-hook timezone?

[Gerald Dachs]

Hi Hanno,

Quoting Hanno Zulla :

> Hi,
>
> what is the timezone of the "next timer" Unixtime/time_t parameter that
> vdr passes to the shutdown-hooks?

Not from knowledge but from experience I can say it is localtime. Your
vdr-addon-acpiwakeup script works only if localtime is UTC and
/sys/class/rtc/rtc0/wakealarm expects POSIX epoch, so it must be localtime.

Gerald


This message was sent using IMP, the Internet Messaging Program.


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

Re: [vdr] shutdown-hook timezone?

[Gerald Dachs]

Quoting Klaus Schmidinger :

> On 18.12.2008 15:06, Gerald Dachs wrote:
>> Hi Hanno,
>>
>> Quoting Hanno Zulla :
>>
>>> Hi,
>>>
>>> what is the timezone of the "next timer" Unixtime/time_t parameter that
>>> vdr passes to the shutdown-hooks?
>>
>> Not from knowledge but from experience I can say it is localtime. Your
>> vdr-addon-acpiwakeup script works only if localtime is UTC and
>> /sys/class/rtc/rtc0/wakealarm expects POSIX epoch, so it must be localtime.
>
>> From VDR/INSTALL:
>
>   The command given in the '-s' option will be called with five parameters.
>
>   The first one is the time (in UTC) of the next timer event or plugin wakeup
>   time (as a time_t type number), ...

I stand corrected. To be honest, I am not sure whether I tested the  
acpi-wakeup
using UTC=no with the vdr. Maybe I started the shutdown hook only by  
hand, making wrong assumptions about the used timezone, sorry.

Gerald




This message was sent using IMP, the Internet Messaging Program.


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

Re: [vdr] 1080p ready VDR

[Gerald Dachs]

> > There are also Mainboards with onboard Nvidia 9300 or 9400 GPU's.
> > They also support VDPAU.
> Hmm, sounds good. I'll search for some of them.

For an AMD 4850e CPU you can use Boards with 8200/8300 GPUs.
They are very similar to the 9300/9400 GPUs on Boards for
Intel CPUs. VDPAU supports the 8200/8300 GPUs, but there
is no official statement whether the codec VC-1 is supported.
Some users got it running, it seems.
A Board with this GPU will be my next, because there are no
9300/9400 Boards with ATX-Form factor and 3 PCI-Slots.

Gerald

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

Re: [vdr] 1080p ready VDR

[Gerald Dachs]

Am Fri, 26 Dec 2008 00:52:49 +0100
schrieb Sascha Vogt :
> Gerald Dachs schrieb:
> >>> There are also Mainboards with onboard Nvidia 9300 or 9400 GPU's.
> >>> They also support VDPAU.
> > For an AMD 4850e CPU you can use Boards with 8200/8300 GPUs.
> > They are very similar to the 9300/9400 GPUs on Boards for
> > Intel CPUs. VDPAU supports the 8200/8300 GPUs, but there
> > is no official statement whether the codec VC-1 is supported.
> It seems not. I found http://www.mythtv.org/wiki/index.php/Vdpau which
> says:
> | VC-1 support in NVIDIA's VDPAU implementation currently requires
> | GeForce 9300 GS, GeForce 9200M GS, GeForce 9300M GS, or GeForce
> | 9300M GS
I have read this thousand times at thousand places, but from
time to time you can find things like this:
http://www.phoronix.com/forums/showpost.php?p=56160&postcount=8


Gerald

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

Re: [vdr] vdr-sxfe + remote control

[Gerald Dachs]

> Do you start vdr with --lirc option? If you use --lirc for vdr-sxfe  
> you should give --lirc to vdr (at least I don't).

No, that will not work. If you give both vdr and vdr-sxfe the option
--lirc you will get every action twice.  I use the option --lirc with
vdr-sxfe and the option --lirc=/dev/null with vdr, so that I can use
lirc with xbmc after I have stopped vdr-sxfe without stopping vdr.

Gerald

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

Re: [vdr] vdr-sxfe + remote control

[Gerald Dachs]

Am Sat, 17 Jan 2009 22:37:47 +0200
schrieb Alex Betis :

> On Sat, Jan 17, 2009 at 10:28 PM, Gerald Dachs 
> wrote:
> 
> > > Do you start vdr with --lirc option? If you use --lirc for
> > > vdr-sxfe you should give --lirc to vdr (at least I don't).
> >
> > No, that will not work. If you give both vdr and vdr-sxfe the option
> > --lirc you will get every action twice.  I use the option --lirc
> > with vdr-sxfe and the option --lirc=/dev/null with vdr, so that I
> > can use lirc with xbmc after I have stopped vdr-sxfe without
> > stopping vdr.
> 
> That's about that I've tried to do.
> 
> How do you stop the vdr-sxfe? Assign a RC button to ESC?
No, I kill it from a script

> How about the repetition setting in vdr-sxfe
I don't know what this is

> if you're not using the
> lircrc?
I use lircrc, but only for starting the script that kills vdr-sxfe
and starts xbmc and vice versa.
 
Gerald

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

Re: [vdr] vdr-sxfe + remote control

[Gerald Dachs]

Am Sun, 18 Jan 2009 00:05:05 +0200
schrieb Alex Betis :
> Doesn't your RC produce multiple pushes when you don't release the
> button in short time?

No

> How do you solve that issue within vdr-sxfe?

I didn't notice it

> Could you also post your remotes.conf as an example? Or at least few
> buttons from it.

I don't have a remotes.conf. I own an OriginAE S16T case with a IR211
module from irtrans. With this module I don't use the lircd but the lirc
compatible irserver. The configuration of it is not lircd compatible,
but the interfaces are, so I can use irexec without a problem.

Gerald

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

[vdr] xineliboutput + vdpau not ready for prime time

[Gerald Dachs]

I have made some experiments with xineliboutput and vdpau, it looked
promising, but at least I had to give up for now. I have used vdr 1.6.0,
xineliboutput 1.0.3, nvidia driver 180.22, xine-lib-vdpau from 20090113
and xinelib 1.1.90hg from 20090114 with vdpau-patch r160.
I use it with sdtv, because I have only DVB-T and a PVR350.
The cpu usage for vdr-sxfe goes down from 25% to 7%, but the picture
is not in sync with the sound. The biggest problem is that if I switch
channels it happens that the video starts to flicker. You can see that
between the pictures of the current channel the pictures of the previous
channel appear. Restarting vdr-sxfe fixes it till the next channel
switch. In the beginning of my test this happened seldom, but now it
happens with every channel switch, the problem is that I have no idea
what configuration change I have done that is to blame.

Does anyone have an idea what I can try next, or should I simply wait
for a better version of the xine-lib for vdpau.

Gerald

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

Re: [vdr] xineliboutput + vdpau not ready for prime time

[Gerald Dachs]

> The biggest problem is that if I switch
> channels it happens that the video starts to flicker. You can see that
> between the pictures of the current channel the pictures of the
> previous channel appear.

I noticed now that it get worst if I use "software scaling" in the
xineliboutput settings for video.

Gerald

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

Re: [vdr] HTPC IR Einschalter Bausatz od. fertig 20 EUR

[Gerald Dachs]

Quoting Lucian Muresan :

> Sorry about this message, please ignore it, it was just meant for later
> reading at home...
>
> Lucian Muresan wrote:
>> http://www.atric.de/IR-Einschalter/index.php
>> http://www.atric.de/IR-Einschalter/com.html
>> http://www.atric.de/IR-Einschalter/download/manual_en_rev4.pdf

:), I can recommend this.

Gerald


This message was sent using IMP, the Internet Messaging Program.


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

Re: [vdr] xineliboutput + vdpau not ready for prime time

[Gerald Dachs]

> I had the same problems. I didn't notice that the picture flickering
> (do you get big patches of mostly green garbage?)

No, not at all, always still pictures that was seen before.

> was triggered by
> channel changes, but that could well be the case.

Only with channel changes here, and only with the option "software
scaling" set to true in xineliboutput.

> 
> I noticed the bad sync too. It seemed to start off slightly out of
> sync and get worse the longer I left it running, but I haven't
> confirmed that.

I didn't have the feeling that it get worse, it seems to be stable.

> I'm using HDMI audio, you'd think the video and sound
> clocks would therefore be derived from the same clock on the NVidia
> chip and it should be easier to avoid loss of sync :-(.

Okay, I don't use HDMI audio, because my receiver is too old for this
and I am even not sure currently whether my Plasma supports HDMI Audio,
will test next chance.

Yesterday I have switched back to the use of vdpau, because I got now
periodically hick ups with xv and xxmc, the last time I had this working
correct I had another CPU, mainboard and nvdida driver :(. The loss of
sync is less disturbing than this periodically stops of motion.

Will soon try the r167 release of the vdpau patch.

Gerald

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

Re: [vdr] xineliboutput + vdpau not ready for prime time

[Gerald Dachs]

> I read something similar on the MythTV mailinglist.
> >From http://www.gossamer-threads.com/lists/mythtv/users/366684:
> > In the end I believe it was accidental code bugs when he was
> > porting the automatic letterboxing patch over to work with VDPAU
> > that caused him to end up with his OSD ghosted over every image
> > displayed via VDPAU. 

Are you sure that this is the right thread? Someone thinks vdpau
has destroyed his video card.

Gerald


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

Re: [vdr] xineliboutput + vdpau not ready for prime time

[Gerald Dachs]

Am Mon, 19 Jan 2009 17:03:34 +
schrieb Tony Houghton :

> On Mon, 19 Jan 2009 17:40:17 +0100
> Gerald Dachs  wrote:
> 
> > Yesterday I have switched back to the use of vdpau, because I got
> > now periodically hick ups with xv and xxmc, the last time I had
> > this working correct I had another CPU, mainboard and nvdida
> > driver :(. The loss of sync is less disturbing than this
> > periodically stops of motion.
> 
> What graphics card/chip have you got? AFAIK xvmc/xxmc only works on
> NVidias up to 7x00 and VDPAU is for 8x00 and newer. If your CPU usage
> dropped significantly with VDPAU it sounds like you didn't actually
> have xxmc working, just plain xv.

I have an onboard Geforce 8200. CPU usage with xv was 27%, with xxmc
22% and with vdpau 7% max. You could be right that xxmc is in reality xv,
because the usage is not very constant, so it could be the same CPU
usage. Anyway, before I could use xv without this hick ups.

Gerald

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

Re: [vdr] xineliboutput + vdpau not ready for prime time

[Gerald Dachs]

Am Mon, 19 Jan 2009 17:40:44 +
schrieb Tony Houghton :
> I'm fairly sure xvmc (which xxmc is based on) isn't supported on
> Nvidia 8x00 and newer. 20-30% CPU usage isn't much problem, so as you
> aren't receiving HD anyway I'd stick with stable drivers, ffmpeg and
> xine etc until VDPAU is known to be stable.

Of course is the cpu usage no problem, but the lost frames
estimated every 10 seconds are, currently xv is not usable for me.
Nothing in the logs to see when it happens.

Gerald

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

Re: [vdr] xineliboutput + vdpau not ready for prime time

[Gerald Dachs]

Am Mon, 19 Jan 2009 21:39:29 +
schrieb Tony Houghton :

> On Mon, 19 Jan 2009 18:57:51 +0100
> Gerald Dachs  wrote:
> 
> > Am Mon, 19 Jan 2009 17:40:44 +
> > schrieb Tony Houghton :
> > > I'm fairly sure xvmc (which xxmc is based on) isn't supported on
> > > Nvidia 8x00 and newer. 20-30% CPU usage isn't much problem, so as
> > > you aren't receiving HD anyway I'd stick with stable drivers,
> > > ffmpeg and xine etc until VDPAU is known to be stable.
> > 
> > Of course is the cpu usage no problem, but the lost frames
> > estimated every 10 seconds are, currently xv is not usable for me.
> > Nothing in the logs to see when it happens.
> 
> Have you tried opengl output?

No, haven't even thought about, will try next chance. Could only
happen that I will try the vdpau patch r167 before ;), I think
I can't resist.

Gerald

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