vdr February 2006

vdr@linuxtv.org

142 participants
169 discussions

Re: [vdr] Streamdev-client and shared video recordings directories.
by Dave 21 Feb '06

21 Feb '06

The client is just a p3 800 mhz, equipped only with a matrox g450 with tv out cable and a via rhine network card fitted with a boot prom. The software resides entirely on the server, which runs the dhcp and tftp servers required for netbooting. Grimmy27 wrote: > Hi, > > I have no solution for your problem but I would be very interested in > a description (hardware & software) of your client machine. > > Thanks in advance, > > Eric. > > Le 19 févr. 06 à 19:08, Dave a écrit : > >> I have a streamdev server-client set up here, the server has 2 dvb >> cards, and handles all the recording. The client with no dvb cards >> using streamdev-client, shares the /video0 and /video1 directories >> via NFS mount, as well as epg.data. The client only ever reads from >> the epg.data. The client is a diskless node, and boots via etherboot >> across the network from the vdr server machine. >> >> My problem is that whilst the server is busy taping recordings, the >> client wont see any new recordings until its restarted and does >> another video directory scan. Is there a way to do this scan every >> so often so recordings will show up on the client? I imagine if I >> wanted to delete recordings from the client, that they as well would >> appear not deleted on the server, until it was also restarted. >> >> Any thoughts on how to get around this (force video directory scan?, >> occasional video directory scan by VDR?) >> >> >> >> _______________________________________________ >> vdr mailing list >> vdr(a)linuxtv.org <mailto:vdr@linuxtv.org> >> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr > > > > > > ------- > > Grim' > >

7 10

RE: [vdr] Streamdev HTTP attach not grabbing a free DVB card?
by Jukka Vaisanen 21 Feb '06

21 Feb '06

Ok, first of all this patch Works For Me. Second, either I'm much too tired to be looking at code or I'm somehow missing the entire channel/device allocation mechanism. I interpret the following happens in the code: - Find a device that could handle the requested channel to be streamed with: device = cDevice::GetDevice(Channel, Priority); - If we don't find a device or the found device is ActualDevice and we can't suspend it.. if (!device || (device == cDevice::ActualDevice() && !cSuspendCtl::IsActive() && StreamdevServerSetup.SuspendMode != smAlways)) { ... Then we go into the special section where we try to find a device by bumping the live tv to another card. It seems to me that we should never be getting to that section AT ALL and cDevice::GetDevice(Channel, Priority) should not give us a device that == cDevice::ActualDevice() since there is an identical budget card free the live tv is on another mux. The fact that this patch works seems to rely on this section: for (int i = 0; i < cDevice::NumDevices(); ++i) { cDevice *dev = cDevice::GetDevice(i); if (dev->ProvidesChannel(current, 0) && dev != device) { newdev = dev; break; } ... where we are trying to find a new device to handle live TV. And in this case instead of relying on cDevice::GetDevice(Channel, Priority) we loop manually through all the devices to see if some other device provides the current live tv channel. If we find it, we either: - (original code) switch live tv to it - (Jose's patch) use that device for the channel to be streamed In both cases I think if that card was already being used for a recording, that recording would get bumped off regardless of any priorities etc. Smells ugly..? First, am I reading this wrong or is the culprit really inside cDevice::GetDevice(...) where it picks the wrong card right at the top of this function? I guess my easiest way out would be to get a third DVB-T card and hard-code each card to a specific MUX but that would cost me 78 euros PLUS this thing would nag me forever ;) - Jukka Vaisanen -----Original Message----- From: vdr-bounces(a)linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Jose Alberto Reguero Sent: 21. helmikuuta 2006 17:30 To: VDR Mailing List Subject: Re: [vdr] Streamdev HTTP attach not grabbing a free DVB card? El Martes, 21 de Febrero de 2006 06:15, BRUNETON Béranger escribió: > Hi, > > I've the same issue on my setup and haven't fix it. > First, you can try a various combinaison of streamdev option(offer > suspend,always suspend...) > > Or try to recompile streamdev with DEBUG = 1 and check in the log file if > you see this message "Found device for live tv" > If you see it that means that your streamdev configuration is ok but > streamdev is unable to reallocate live tv on a free dvb card. > and the following method "connection.c: > cServerConnection::GetDevice" is guilty. I solved this changin in cServerConnection::GetDevice: if (newdev == NULL || newdev == device) // no suitable device to continue live TV, giving up... device = NULL; else newdev->SwitchChannel(current, true); by: if (newdev == NULL || newdev == device) // no suitable device to continue live TV, giving up... device = NULL; else // newdev->SwitchChannel(current, true); device = newdev; Jose Alberto > > A dirty solution would to never allocate the primary card for streaming. > > I will check deeper in the source code and go back to you if I found > interesting things. > > Regards > > On 2/20/06, Jukka Vaisanen <Jukka.Vaisanen(a)exomi.com> wrote: > > I recently moved on to the wonderful world of multiple DVB-T cards in my > > VDR and also set up streamdev-server for use with VLC for > > HTTP/PES-streams to a remote PC. However I ran into a problem with how > > streamdev and my primary output coexist. > > > > Software: > > - vdr-1.3.43 > > - DVB drivers from 2.6.15-gentoo-r1 kernel > > - dxr3-0.2.5 plugin > > - Latest streamdev-cvs (Jan 20) > > > > Hardware: > > - 2x Airstar2 budget DVB-T (FlexCopIIb) > > - DXR3 (Hollywood+) > > - P3/800 + 1.5GB RAM > > > > And how / what happens: > > > > - I restart VDR "fresh" with only dxr3 and streamdev plugin loaded > > - I switch my primary output (dxr3) to the preferred channel, works fine > > - I connect via the streamdev HTTP server to a channel which is on > > another mux and my dxr3 output switches to the first channel in that > > mux. Apparently the streamdev is somehow grabbing the same budget card > > and forcing the mux switch. > > - If I disconnect the streamdev client and reattach it to yet another > > mux the dxr3 changes channels again. It "follows" my streamdev actions. > > - After a few channel switches the dxr3 video freezes into a still frame > > but I can still attach to streamdev via HTTP to any channel/mux without > > any problems. > > - If I now switch a channel on the dxr3 output to anything on the same > > mux as the streamdev, it works fine but the picture freezes again every > > time I switch to another mux from the streamdev. > > - If I switch the dxr3 channel to another mux while the streamdev HTTP > > is serving something, the entire problem goes away. After this I can > > independently use dxr3 and the streamdev without any conflicts until the > > next VDR restart. > > > > My not-so-educated guess is that the streamdev receiver device is using > > GetDevice to find a tuner and it manages to magically grab the primary > > device every time whether it's in use or not. If the dxr3 is using the > > primary device, it gets thrown over to the other mux by virtue of using > > that tuner. If I change the channel on the dxr3 while the streamdev is > > connected, the dxr3 gets assigned to the other DVB card and from then on > > they both coexist peacefully. > > > > This is a minor nuisance in the sense that I can live with my live tv > > being knocked onto another channel now and then but what I'm worried > > about is recordings.. If I have a recording on the primary device and > > the HTTP streamdev client connects, the recording might get cut off or > > switch to the wrong channel. > > > > I did a bit of source-code surfing to try and understand the mechanism > > by which streamdev gets a tuner device but I couldn't really identify > > any clearly faulty logic. I'd suppose that others would have run into > > this issue already but mailing list search and Google turned up nothing > > really relevant. Since this is easily reproducible here and I'm running > > pretty much latest everything here, I could try and patch this up if > > someone points me in the right direction. > > > > - Jukka Vaisanen > > > > > > _______________________________________________ > > vdr mailing list > > vdr(a)linuxtv.org > > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr _______________________________________________ vdr mailing list vdr(a)linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

2 1

Streamdev HTTP attach not grabbing a free DVB card?
by Jukka Vaisanen 21 Feb '06

21 Feb '06

I recently moved on to the wonderful world of multiple DVB-T cards in my VDR and also set up streamdev-server for use with VLC for HTTP/PES-streams to a remote PC. However I ran into a problem with how streamdev and my primary output coexist. Software: - vdr-1.3.43 - DVB drivers from 2.6.15-gentoo-r1 kernel - dxr3-0.2.5 plugin - Latest streamdev-cvs (Jan 20) Hardware: - 2x Airstar2 budget DVB-T (FlexCopIIb) - DXR3 (Hollywood+) - P3/800 + 1.5GB RAM And how / what happens: - I restart VDR "fresh" with only dxr3 and streamdev plugin loaded - I switch my primary output (dxr3) to the preferred channel, works fine - I connect via the streamdev HTTP server to a channel which is on another mux and my dxr3 output switches to the first channel in that mux. Apparently the streamdev is somehow grabbing the same budget card and forcing the mux switch. - If I disconnect the streamdev client and reattach it to yet another mux the dxr3 changes channels again. It "follows" my streamdev actions. - After a few channel switches the dxr3 video freezes into a still frame but I can still attach to streamdev via HTTP to any channel/mux without any problems. - If I now switch a channel on the dxr3 output to anything on the same mux as the streamdev, it works fine but the picture freezes again every time I switch to another mux from the streamdev. - If I switch the dxr3 channel to another mux while the streamdev HTTP is serving something, the entire problem goes away. After this I can independently use dxr3 and the streamdev without any conflicts until the next VDR restart. My not-so-educated guess is that the streamdev receiver device is using GetDevice to find a tuner and it manages to magically grab the primary device every time whether it's in use or not. If the dxr3 is using the primary device, it gets thrown over to the other mux by virtue of using that tuner. If I change the channel on the dxr3 while the streamdev is connected, the dxr3 gets assigned to the other DVB card and from then on they both coexist peacefully. This is a minor nuisance in the sense that I can live with my live tv being knocked onto another channel now and then but what I'm worried about is recordings.. If I have a recording on the primary device and the HTTP streamdev client connects, the recording might get cut off or switch to the wrong channel. I did a bit of source-code surfing to try and understand the mechanism by which streamdev gets a tuner device but I couldn't really identify any clearly faulty logic. I'd suppose that others would have run into this issue already but mailing list search and Google turned up nothing really relevant. Since this is easily reproducible here and I'm running pretty much latest everything here, I could try and patch this up if someone points me in the right direction. - Jukka Vaisanen

5 4

Re: [vdr] Audio channel problem
by Antti Hartikainen 21 Feb '06

21 Feb '06

> Hello > > I have problem in VDR version 1.3.42 and 1.3.43. > When I switching audio channels, I see only numbers instead of short-name of > audio track. > In VDR 1.3.41 everything is OK. > Does anybody has the same problem? Confirmed. Only audio track number is displayed. But now audio track names work when replaying! ;-) But when replaying recording, preferred audio track is not selected, but the first track found (as it was previously, when audio track names doesn't work.)

3 4

Mplayercluster-plugin crashes with long NFS paths
by Teppo Jalava 21 Feb '06

21 Feb '06

Hi It seems that there is some memory problems with mplayercluster plugin when using NFS-path mapping and the server side path gets big enough. I did some testing and noticed that the critical length of the file path is somewhere near 58 characters. Exeeding that the VDR crashes every time. The standard output from VDR looks like this when trying to play a file that's remote path is "/mnt/media/movies/The Office/The Office - S - Downsize.avi": cretincreting 137789880 sende initpaket ende initpaket deleting 137789880 nach delete *** glibc detected *** malloc(): memory corruption: 0x083682a0 *** If I shorten the filename the file plays OK and VDR stays running. I'm using VDR-1.3.42 and I have patched the plugin with "mplayercluster-0.0.1a-Urig8.diff" I'll try to debug the plugin and see if I can find out more information about this. -- t.

2 3

RE: [vdr] Audio channel problem
by Radek Rous 20 Feb '06

20 Feb '06

> Radek Rous wrote: > > Hello > > > > I have problem in VDR version 1.3.42 and 1.3.43. > > When I switching audio channels, I see only numbers instead > of short-name of > > audio track. > > In VDR 1.3.41 everything is OK. > > Does anybody has the same problem? > > Can you provide a detailed sequence of actions (together with > the appropriate channel definition(s)) that leads to this, so > that I can reproduce it? > > Klaus I compile VDR 1.3.43 only with xine plugin and use channels.conf from sources. Switch to channel 1 - RTL Television. One audio channel is marked "1" Switch to channel 2 - SAT.1. Two audio channels are marked "deutsch" and "dolby digital" Switch to channel 3 - ProSieben. Two audio channels are marked "deutsch" and "dolby digital" Switch to channel 4 - RTL2. One audio channel is marked "1" I compile VDR 1.3.41 only with xine plugin and use channels.conf from sources. Switch to channel 1 - RTL Television. One audio channel is marked "deu" Switch to channel 2 - SAT.1. Two audio channels are marked "deutsch" and "dolby digital" Switch to channel 3 - ProSieben. Two audio channels are marked "deutsch" and "dolby digital" Switch to channel 4 - RTL2. One audio channel is marked "deu" Radek

1 0

Re: [vdr] Audio channel problem
by Klaus Schmidinger 20 Feb '06

20 Feb '06

Radek Rous wrote: > Hello > > I have problem in VDR version 1.3.42 and 1.3.43. > When I switching audio channels, I see only numbers instead of short-name of > audio track. > In VDR 1.3.41 everything is OK. > Does anybody has the same problem? Can you provide a detailed sequence of actions (together with the appropriate channel definition(s)) that leads to this, so that I can reproduce it? Klaus

1 0

Audio channel problem
by Radek Rous 20 Feb '06

20 Feb '06

Hello I have problem in VDR version 1.3.42 and 1.3.43. When I switching audio channels, I see only numbers instead of short-name of audio track. In VDR 1.3.41 everything is OK. Does anybody has the same problem? Thanks Radek

1 0

[PATCH] GetFollowingEvent
by Pekka Mauno 20 Feb '06

20 Feb '06

Hi, I contribute this small patch for method const cEvent *cSchedule::GetFollowingEvent(void) const in epg.c. It fixes the behaviour of method GetFollowingEvent in situation, where present event/program has reached the end and the next event has not started yet. Vanilla method returns NULL, because method GetPresentEvent returns NULL and so it is unable to return the next event. Patched version tries to find next event, which has not started. Here inline and also as attachment. ----8<---8<--- diff -Nru vdr-1.3.43/epg.c vdr-1.3.43-fixed/epg.c --- vdr-1.3.43/epg.c 2006-02-19 14:50:26.000000000 +0200 +++ vdr-1.3.43-fixed/epg.c 2006-02-20 20:38:19.000000000 +0200 @@ -692,6 +692,16 @@ const cEvent *p = GetPresentEvent(); if (p) p = events.Next(p); + else { + // Get next event, if it exists + time_t now = time(NULL); + for (cEvent *pe = events.First(); pe; pe = events.Next(pe)) { + if (pe->StartTime() >= now) { + p = pe; + break; + } + } + } return p; } -----8<---8<--- Pekka -- Pekka Mauno, still emailing as novice

1 0

Re: [linux-dvb] How might a SATA drive interfere with DVB-S
by Gregoire Favre 20 Feb '06

20 Feb '06

On Mon, Feb 20, 2006 at 06:10:06PM +0100, Robert Schlabbach wrote: > What chipset do you have on your motherboard? If this is an AMD64 machine, > do you have Cool&Quiet enabled? If you do, try disabling Cool&Quiet and see > if that helps. What's the problem with Cool&Quiet under AMD64 ??? I use it every day without any trouble at all, also with SATA... -- Grégoire FAVRE

1 0

← Newer
1
2
3
4
5
6
7
8
...
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

vdr February 2006