Re: [vdr] UPnP/DLNA media server plugin for the VDR
On 01/04/2013 07:48 PM, Brian-Imap wrote:
Hi,
this looks to be pretty interesting.
So where exactly does it fit in between XVDR, VNSI, streamdev, etc.
I just bought a Samsung smart TV, haven't found a single DLNA
music server that it could receive music from (sure I've heard about
updating the headers that are sent from the server), still none of them
worked with the TV.
Seems I could watch VDR directly on the TV without any kind of Set-Top
box inbetween with this plugin.
Samung has some bug's in their handling of upnp messages and therefore a
MediaTomp requires for example a small patch so that samsung tv is able
to show the media listing and play the recordings.
I patched the Mageia's mediatomb-0.12.1-4.mga2.src.rpm version with the
attached patch (found somewhere from the net) and at least Samsung 6305
with newest software works now ok with mediatomb.
Mika
diff -ruN mediatomb.orig/tombupnp/upnp/src/genlib/net/uri/uri.c mediatomb/tombupnp/upnp/src/genlib/net/uri/uri.c
--- mediatomb.orig/tombupnp/upnp/src/genlib/net/uri/uri.c 2012-06-06 23:01:22.0 +0200
+++ mediatomb/tombupnp/upnp/src/genlib/net/uri/uri.c 2012-06-07 08:22:01.0 +0200
@@ -1042,7 +1042,8 @@
out-path_type = REL_PATH;
}
-if( ( ( begin_hostport + 1 ) max ) ( in[begin_hostport] == '/' )
+//parse hostport only if scheme was found
+if( ( begin_hostport 0 ) ( ( begin_hostport + 1 ) max ) ( in[begin_hostport] == '/' )
( in[begin_hostport + 1] == '/' ) ) {
begin_hostport += 2;
@@ -1059,6 +1060,12 @@
out-hostport.text.size = 0;
out-hostport.text.buff = 0;
begin_path = begin_hostport;
+
+//remove excessive leading slashes (fix for Samsung Smart TV 2012)
+while( ( ( begin_path + 1 ) max ) ( in[begin_path] == '/' ) ( in[begin_path + 1] == '/') ) {
+begin_path++;
+}
+
}
begin_fragment =
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.35 Makefile woes
Hi Torsten, please try this patch against VDR 1.7.35. http://www.vdr-portal.de/index.php?page=AttachmentattachmentID=32523 At VDR-Portal we currently try to repair the whole Makefile stuff. It's time to post it on the Mailinglist. Christopher Reimer 2013/1/5 Torsten Duwe d...@lst.de: Hi all! This may or may not be related to the Make.config discussion. I'm having difficulties to package vdr-1.7.35 compiled along with some plugins; make install produces nonsense under $DESTDIR, no matter whether I change $UP3 to use `pwd` or not. libdir and locdir always contain $UP3, which is always incorrect. I haven't even tried yet to compile other plugins against the installed vdr package. Please correct me if I'm wrong, IMHO there's a difference between the place where vdr is compiled, and the final runtime on the target system. Thus, if you stick to the package-config approach, 2 separate vdr.pc files would be required: one for the plugins compiled along with vdr, and one to be installed on the target system. I also fail to see this differentiation in the Makefile: LOCDIR and PLUGINDIR (and derived LIBDIR) appear only once in it, not to talk about INCDIR, see above. All contain $CWD. What am I missing? Torsten ___ 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-1.7.35 Makefile woes
On Sat, 5 Jan 2013, Christopher Reimer wrote:
Hi Torsten,
please try this patch against VDR 1.7.35.
http://www.vdr-portal.de/index.php?page=AttachmentattachmentID=32523
Ah, much better! Only xineliboutput still dumps additional .mo files
under DESTDIR/Compiledir and tries to remove .so files from the running
system. Only 1 plugin to fix...
At VDR-Portal we currently try to repair the whole Makefile stuff.
I have 1.7.35 running now, after applying attached patch.
Thanks for all the work!
Torsten
--- vdr-1.7.35/PLUGINS/src/dvbhddevice/dvbhdffdevice.c.orig 2012-12-29
14:23:22.0 +0100
+++ vdr-1.7.35/PLUGINS/src/dvbhddevice/dvbhdffdevice.c 2013-01-05
18:07:36.272558711 +0100
@@ -951,8 +951,13 @@ bool cDvbHdFfDeviceProbe::Probe(int Adap
// --- YuvToJpeg -
-
+extern C {
+#ifdef boolean
+#define HAVE_BOOLEAN
+#endif
#include jpeglib.h
+#undef boolean
+}
#define JPEGCOMPRESSMEM 400
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.35 Makefile woes
On Sat, Jan 5, 2013 at 5:44 AM, Christopher Reimer c.reimer1...@gmail.com wrote: At VDR-Portal we currently try to repair the whole Makefile stuff. It's time to post it on the Mailinglist. Has the Makefile stuff been completely resolved now or is there still debate going on? If it's a done deal, could you summarize what the final decision is? Thanks ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.35 Makefile woes
On 05.01.2013 22:36, VDR User wrote: On Sat, Jan 5, 2013 at 5:44 AM, Christopher Reimer c.reimer1...@gmail.com wrote: At VDR-Portal we currently try to repair the whole Makefile stuff. It's time to post it on the Mailinglist. Has the Makefile stuff been completely resolved now or is there still debate going on? If it's a done deal, could you summarize what the final decision is? It's not final yet - but hopefully soon ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Permissions in vdr-1.7.35 tarball
Am 05.01.2013 13:16, schrieb Klaus Schmidinger: Looks like this was caused by an NFS problem on my system. Will be OK again in the next version. While on packaging, you might want to check for some empty folders that get packaged. Last version had a locale/ tree and a PLUGINS/src/dvbhddevice/locale/ tree with just folders, no files. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Tuning timeouts blocks the other adapter
Mariusz Bialonczyk wrote:
On 11/10/2012 12:12 AM, Mariusz Bialonczyk wrote:
Is it possible that it is caused by some global lock or mutexes
in VDR?
Hello
It seems the cause of the problem has been located by Alex Pipelka.
The vdr freezes occurs when obtaining the signal strength/quality
with functions SignalStrength() and/or SignalQuality()
and when non-busy adapter has tunining issues
(frontend x/x timed out while tuning to channel ...).
It occurs only on multi adapters systems (one adapter is doing
EIT scan and the other is used, eg for a live-tv).
Guys, any thoughts on this?
I think it may be even kernel/drivers related issue.
some details in commit discussion:
https://github.com/pipelka/vdr-plugin-xvdr/commit/d3982714
I am running vdr 1.7.34 with a TT S2 6400 card on a dual core Intel Atom
1.8GHz board and believe I may be seeing these issues.
They manifest as intermittent video/audio disturbances of less than one
frame duration - the audio usually gives a squawk.
I tried adding the suggested patch to vdr in the above thread:
diff -ur vdr-1.7.35-org/dvbdevice.c vdr-1.7.35/dvbdevice.c
--- vdr-1.7.35-org/dvbdevice.c 2012-12-30 12:27:39.0 +0100
+++ vdr-1.7.35/dvbdevice.c 2013-01-03 14:34:30.997489765 +0100
@@ -1510,12 +1510,12 @@
int cDvbDevice::SignalStrength(void) const
{
- return dvbTuner ? dvbTuner-GetSignalStrength() : -1;
+ return -1;
}
int cDvbDevice::SignalQuality(void) const
{
- return dvbTuner ? dvbTuner-GetSignalQuality() : -1;
+ return -1;
}
const cChannel *cDvbDevice::GetCurrentlyTunedTransponder(void) const
It's possible it has improved the situation - no longer getting audio
disturbances, but there are still very short duration video glitches.
In an effort to eliminate the second tuner scanning empty channels as
the cause, I set, UpdateChannels = 0 in setup.conf, but it appears to
not have the desired effect:
Jan 6 16:47:27 atom vdr: [790] frontend 1/0 timed out while tuning to
channel 487, tp 212651
Jan 6 16:47:47 atom vdr: [790] frontend 1/0 timed out while tuning to
channel 124, tp 212671
Jan 6 16:48:08 atom vdr: [790] frontend 1/0 timed out while tuning to
channel 71, tp 212680
Jan 6 16:48:50 atom vdr: [790] frontend 1/0 timed out while tuning to
channel 110, tp 112280
Is there some way I can stop the unused tuner from scanning altogether?
Regards,
Richard
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
