vdr January 2006

vdr@linuxtv.org

153 participants
203 discussions

Modified channels.conf isn't saved
by Philippe Gramoullé 20 Jan '06

20 Jan '06

Hello, I apology if this subject has already been discussed before, but i couldn't find any definitive answer to my problem : Sometimes i don't tune in some given channels for some time, just to realise that the channel's name has changed. I started to reorganise my channels.conf using VDR "mark channels" then move them up/down, and after i was done i zapped through channels for a while and then shut down VDR. I was disappointed to see that my changes weren't saved and that i had to start all over again. So what's the best way to avoid such a mistake ? - tune to somme channels, wait a few seconds that names (and pids) are updated, write the list down, and then manually edit channels.conf with a text editor ? - use a plugin (channelsort) ? - wait some time so that VDR writes the changes down ? (i don't remember what are the conditions so that VDR triggers files update, IIRC, no epg scan, no activity for xx minutes) My config has only one FF DVB-S card. Thanks much, Philippe PS: same problem would eventually occur to epg data, so any advice is welcome as well to handle epg data updates.

2 2

BUG: short directoryname disturbs the Recordinglist - Privat
by christian jacobsen 20 Jan '06

20 Jan '06

Hallo, I noticed something strange, if there are short directorynames the the recording list gest disturbed. I also posted this here (with a screenshot) : http://www.vdr-portal.de/board/thread.php?sid=&postid=380360#post380360 A bit further down in the thread MarkusE thinks it has something with the sorting to do. It happens with a directory named "S" - see treelist below, and it must have something with the deepnes of the direcory-structure to do as it does not happen on another directory "M" that I have got. The "M" directory has got on level less than "S" - meaning : M/REC-Name/2005-11-01.20.12.20.99.rec Tested with vanilla VDR 1.3.34 - but still there in 1.3.38 Here a structure that makes it happen : # tree S S |-- CSI__Miami | `-- Die_Todeswelle | `-- 2005-11-01.20.12.20.99.rec | |-- 001.vdr | |-- 002.vdr | |-- 003.vdr | |-- index.vdr | |-- info.vdr | |-- marks.vdr | `-- vdr-starttime `-- NUMB3RS `-- Hinterhalt `-- 2005-11-07.21.07.20.99.rec |-- 001.vdr |-- index.vdr |-- info.vdr |-- marks.vdr `-- vdr-starttime Greetings Christian Jacobsen

2 2

Stupid provider / channel name notifications
by Gavin Hamill 20 Jan '06

20 Jan '06

My cable provider seems to send very odd name updates. e.g. Jan 20 11:55:17 localhost vdr[3085]: changing name of channel 2032 from 'TheHitsR,;The Hits Radio' to 'The Hits Radio,;The Hits Radio' Jan 20 11:55:17 localhost vdr[3085]: changing name of channel 2032 from 'The Hits Radio,;The Hits Radio' to 'TheHitsR,;The Hits Radio' I will get one pair of these messages for every service on that multiplex, so every time I change to a new multiplex frequency, I'll get a dozen or so sets of these messages in my syslog - a bit irritating. Unfortunately, it means that I always end up seeing the short name like 'TheHitsR' in the VDR (and VDRAdmin) channel lists when I would much rather have the 'Provider' name after the semicolon displayed as the channel name. Is there a one-line twiddle I can change for this? I've had a look through the source, but I'm not a coder so it's a bit needle-in-a-haystack :) Cheers, Gavin.

1 0

Feature Request: EPG: switch between channels and stay at same point in time...
by Laurence Abbott 20 Jan '06

20 Jan '06

I'm afraid I've come up with another request for a feature. I don't _think_ this is currently possible but I've been fooled before! ;-) The main way I set timers is to get a newspaper at the weekend and go through the TV-guide setting timers as I see fit. This means that I will set timers for Saturday, Sunday, Monday, etc. in turn for whichever channels. Currently, once I've finished one day and move on to the next, the schedule listing is set back to the current day whenever I switch from the EPG of one channel to another and I have to scroll down a long way to get back to where I was with the previous channel. Something I would find really useful, is to be able to switch between the EPG for different channels but stay at the same point in time, i.e. if I'm looking at Chan 1 at 5:30 pm for next Tuesday, I'd like to be able to switch to the EPG for Chan 2 for 5:30 pm next Tuesday, rather than it going back to the current day when I switch to Chan 2. Does that make sense? I'm, hoping you'll say that it's already possible by pressing keys 'x' and 'y' from the EPG! If not, I reckon it would make the schedule much easier to use in this way. Keep up the good work! Cheers, Laz

2 2

RE: [vdr] BUG: short directoryname disturbs the Recordinglist - Privat
by christian jacobsen 20 Jan '06

20 Jan '06

Hallo Klaus, > > I noticed something strange, if there are short > directorynames the the > > recording list gest disturbed. I also posted this here (with a > > screenshot) : > > > http://www.vdr-portal.de/board/thread.php?sid=&postid=380360#p > ost380360 > > > > It happens with a directory named "S" - see treelist below, > > Does this go away if you rename the "S" directory to, say, > "SSSSSSSSSSSSSSSSSSSS"? Yes, as soon as I rename the directory to SS and touch .update it is OK. Rename it back to S and the problem is there again. Greetings Christian Jacobsen

1 0

RFC: Installing vdr to /usr(/local)/sbin
by Ville Skyttä 20 Jan '06

20 Jan '06

As mentioned in a private mail to Klaus: I tend to think /usr(/local)/sbin and manual page section 8 would be more appropriate for vdr than /usr(/local)/bin and section 1. Even though "sbin" and section 8 is generally for "system administration commands", which vdr clearly is not, in my opinion vdr is even less a "user command" which "bin" and section 1 more or less implies. No need to clutter normal users' PATH with executables they aren't really supposed to run. Additionally, the vast majority of daemon-like programs are installed to sbin directories by all distributions I'm aware of. So, what do people think, would something like the attached patch be a good idea? It might break some setups, so it clearly needs to be done during a development cycle if ever. While sort of cosmetic, I think this would be a good thing, and in the series of making vdr feel "more mature" like someone mentioned in a recent "don't run as root" thread. Obviously, after applying the patch, vdr.1 should be renamed to vdr.8.

3 2

Channel 0?
by s.huelswitt＠gmx.de 19 Jan '06

19 Jan '06

Hi, I'm using vdr 1.3.39 and often I see messages like: Jan 19 17:36:46 video vdr[31577]: frontend 1 lost lock on channel 0, tp 212207 Jan 19 17:36:46 video vdr[31577]: frontend 1 regained lock on channel 0, tp 212207 Jan 19 17:36:47 video vdr[31577]: frontend 1 lost lock on channel 0, tp 212207 Jan 19 17:36:48 video vdr[31577]: frontend 1 regained lock on channel 0, tp 212207 Jan 19 17:36:50 video vdr[31577]: frontend 1 lost lock on channel 0, tp 212207 Jan 19 17:37:22 video last message repeated 6 times Jan 19 17:37:29 video vdr[31577]: frontend 1 lost lock on channel 0, tp 212207 Jan 19 17:37:30 video vdr[31577]: frontend 1 regained lock on channel 0, tp 212207 Jan 19 17:37:31 video vdr[31577]: frontend 1 lost lock on channel 0, tp 212207 Jan 19 17:37:36 video vdr[31577]: frontend 1 lost lock on channel 0, tp 212207 As appearently the channel numbering starts with 1, I'm wondering what the heck is channel 0? Regards. -- Stefan Huelswitt s.huelswitt(a)gmx.de | http://www.muempf.de/

2 2

strange cPalette::SetBpp
by Markus Hahn 19 Jan '06

19 Jan '06

Hi there, with none default themes, I get the error messages like: "too many different colors used in palette" by using 16 different colors in theme file. As a result some Skins.Message are not displayed Digging deeper, I found cPalette::SetBpp osd.c give some strange values: At Start maxColors: 256 maxColors: 2 maxColors: 256 maxColors: 4 first call up menu maxColors: 16 maxColors: 4 etc. Why does the color resolution changed? Shoudn`t be at one value? regards Markus

2 1

RE: [vdr] Show device-number when writing error messages to syslog
by christian jacobsen 19 Jan '06

19 Jan '06

Hallo, > :) It would > >be really nice if the VDR error/info messages also could tell on what > >device the problem happened. > > > >I find lines like this in the syslog but as I were recording and live > >viewing at the time I don't know what really happened ;) > > > >clearing device because of consecutive poll timeouts > >cDolbyRepacker: skipped 238 bytes while syncing on next AC3 frame > >cAudioRepacker(0xC0): skipped 24 bytes to sync on next audio frame > >cVideoRepacker: no valid PES packet header found (dropped 201 bytes) > >cVideoRepacker: skipped 583 bytes while syncing on next picture > > > Just search for the Message, change the output and make a diff. If I was able to programm I would have sent a patch ;) > But as I know the remux don't know for which device it will > do the work. OK, if it is possible I can't say, but maybe it can be made possible ;) > But you are right, sometimes it would be very nice to know > which device > makes Problems. Indeed :) > Btw it would be nice to know whats behind the devicenumber. Is it > possible to detect that the first device is my DVB-S FF TT > 1.5 ?? Maybe > the Name of the device would be nice. Name would only help if you use different cards, Device number should be enough. Greetings Christian Jacobsen

1 0

Show device-number when writing error messages to syslog
by christian jacobsen 19 Jan '06

19 Jan '06

Hallo, Only a small wish that can help if one is searching for bugs :) It would be really nice if the VDR error/info messages also could tell on what device the problem happened. I find lines like this in the syslog but as I were recording and live viewing at the time I don't know what really happened ;) clearing device because of consecutive poll timeouts cDolbyRepacker: skipped 238 bytes while syncing on next AC3 frame cAudioRepacker(0xC0): skipped 24 bytes to sync on next audio frame cVideoRepacker: no valid PES packet header found (dropped 201 bytes) cVideoRepacker: skipped 583 bytes while syncing on next picture There might also be other messages that need this kind of information, but that are the ones that I stumbled across. Thanks Christian Jacobsen

2 1

← Newer
1
...
7
8
9
10
11
12
13
...
21
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 January 2006