Hi,
now that my VDR works fine with 2 satellites thanks to the help of some
kind folks here and the SourceCaps patch (did I mention it should be in the
mainstream VDR?) I have now a couple of FTA programmes in russian language
for my better half :-) The only problem is, none of these programmes carry
any EPG information. The schedules are available on the web sites, mostly.
Has somebody written a plugin that retrieves the schedules and creates
proper EPG data from them? I might but not too …
[View More]soon... I understand this
task can be a pain in <pick your favourite body part> because people use no
SOA interfaces. TBNRussia provides an Excel file (yuck).
TIA!
--
Reader, suppose you were an idiot. And suppose you were a member of
Congress. But I repeat myself.
-- Mark Twain
[View Less]
in cPluginRadio::Replaying(), radio.c expects the replayed recording to be
a VDR record. But mp3plugins like mp3, music, muggle use this mechanism for
simple audio files.
So if both plugins are loaded, radio will emit messages like
vdr: [16883] ERROR: /Musik/shout/Bach/Johann Sebastian Bach - Adagio ma non tanto.mp3/001.vdr: Ist kein Verzeichnis
Now my question is: Is this mechanism is thought to be used only for
VDR recordings ore more generally - the latter I hope.
A simple solution would …
[View More]be if the radio plugin could check if the
recording is actually a VDR recording. Right now it just calls
cFileName fn(FileName, false, true);
maybe a VDR core helper function like isVDRRecording would be helpful
for this.
--
Wolfgang
[View Less]
Hiho,
I recently upgraded to VDR from 1.4 to 1.6.0 and sadly there is a
regression from a bug which was fixed in VDR 1.4.1. The problem is
described (with patches) in this thread:
http://www.linuxtv.org/pipermail/vdr/2006-August/010312.html
The changelog entry of the fix:
2006-08-13: Version 1.4.1-4
- Changed the way a device is selected for receiving in
order to keep devices with CAMs better available, even
if this means recording on the primary device (reported
by Jörn Reder; …
[View More]thanks to Anssi Hannula for improving
handling Transfer Mode devices in this).
With vdr 1.4 this worked perfectly, now with 1.6 VDR always prefers my
Budget CI card for recordings so I can't view any Pay TV when a
recording is active.
Obivously I vote for changing 1.6 to the old behaviour again ;)
Thanks,
Jörn
--
$a=$a[8][67][9][0][42][214][82][78][0][50][69][68][69][82][0][73][78][0]
[65][0][20][16][0][68][73][77][69][78][83][73][79][78][65][76][0][65][82
][82][65][89]=sub{sub _($){print$_[@z]}($z,$i)=@_;(++$i)while!$z->[$i];$
s+=$i;_ chr($i+32);$s!=2292&&&$a($z->[$i],$c>>$e)};&$a(\@a,$d<<$f);_"\n"
[View Less]
On Sun, Dec 7, 2008 at 9:43 AM, Klaus Schmidinger
<Klaus.Schmidinger at cadsoft.de <http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr>> wrote:
> On 07.12.2008 18:40, gimli wrote:
>> / Hi Klaus,
> />/ />/ just one question. Do you also use a budget system ?
> />/ If so, how do you watch TV with vdr 1.7.1 and later ;)
> />/ since xineliboutput is completly broken with it.
> /
> Currently I still have a FF DVB card for replaying, which, in
> …
[View More]the long run, will be replaced by an eHD card.
>
> Klaus
>
>
I hope you don't buy an eHD card since I don't believe it's the way to
go and it would drive VDR in the wrong direction. I'm sitting here with
a €65 nvidia 8200-based motherboard playing 1080p videos with the cpu
97% idle using vdpau and ffmpeg! That's NOT software decoding if you ask
me. And now that hdmi audio finally works with nvidia it's just awesome.
I REALLY hope the xine guys will get this running soon.
Btw, thanks to Klaus and the rest for all the work you put into this.
/Magnus H
[View Less]
Hello!
A new version of the VDR OSDTeletext plug-in was just released.
Recent Changes:
- switched completely to VDR 1.6's I18N system and removed the old
crap - no more support for older VDR versions! (thx to Rolf Ahrenberg)
- proper translation of the key bindings (thx to Rolf Ahrenberg)
- Partially updated Italian translation by Davide Cavalca
TODO:
Currently the translations need to be updated. Only Finnish and German are
up-to-date at the moment. Please post translations for your …
[View More]language to
the projects issue tracker.
Development site:
http://projects.vdr-developer.org/projects/show/plg-osdteletxt
Downloads:
http://projects.vdr-developer.org/projects/list_files/plg-osdteletext
Git-Web:
http://projects.vdr-developer.org/git/?p=vdr-plugin-osdteletext.git
Anonymous Git-access :
git://projects.vdr-developer.org/vdr-plugin-osdteletext.git
This is intended to be a community maintained project! Don't expect me
to fix your problems, I'm merely maintaining the project!
Please report any bugs, ideas or feature requests to the project site (no
registration required for this!). If you want to contribute patches, new
features or whatever, post an issue or patch to the projects issue tracker
or request to join the project. I would happily add everyone as a project
member, who would like to contribute to the project!
If you want to contribute but don't know what to do - start with some code
refactoring!
Tobias
[View Less]
For testing purposes, a new version of my plugins' development branch
is available.
Download as usual from http://www.joachim-wilke.de/vdr-fritz.htm
--- 8< ---
2008-12-20: Version 1.1.3
- added a missing const in cTcpClient::&operator<<
- fixed wrong type in comparisons to size_t in cFritzListener, cFritzTools
- fixed wrong type in dsyslog output in cNotifyOsd, cLocalFonbuch,
cMenuSetupFritzboxFonbooks
- fixed compiler warning wrt comparison in cNotifyOsd
- updated italian …
[View More]translations (provided by Diego [24])
- implemented reverse lookup function for +31 (Netherlands)
- adapting plugin to new Fritz!Box firmware versions:
* auto detecting charset encoding when retrieving phonebook entries
* modified interface language detection (currently using a
trial-and-error approach,
because old approach is no longer supported by newest firmware)
- splitted plugin into plugin application and three static libraries
* libfritz++ (included all Fritz!Box specific functionality)
* libtcpclient++ (providing tcp socket communication)
* libpthread++ (providing pthread support, independant of VDRs
implementation)
With this, it is possible to use these libraries in other projects
not related to VDR.
- all socket communication of the plugin can now be traced into
/tmp/tcpclient.trace.
If this file exists at VDR startup, tracing is enabled. If not,
tracing is disabled.
If you experience problems with vdr-fritzbox, this trace may be
helpful in debugging
the issue. However, please be aware that this trace may contain
password and other
sensitive information.
- modified logging to syslog. All log entries related to this plugin are now
prefixed with "vdr-fritzbox:".
- removed memory leak in cMenuSetupFritzbox::Store[MSN|Fonbooks]
- fixed some compiler warnings that occur with recent compiler versions (4.3.x)
- fixed missing includes which prevented compilation with recent
compiler versions (4.3.x)
--- 8< ---
--
Best Regards,
Joachim.
[View Less]
Hi,
I'm using xineliboutput on 3 VDR clients, sharing the same NFS root FS.
All clients are a bit different, and I solved most of the issues with a
separate VDR config dir for each client, basically running "/usr/bin/vdr
-c /var/lib/vdr.$(hostname) ...".
The problem is that xineliboutput seems to use a single
~/.xine/config_xineliboutput config file, stored in the home directory
of the vdr user, which is defined by /etc/passwd, which is the same on
all clients...
Is there a way to tell …
[View More]xineliboutput which file to use ? Like adding a
command-line param "--config=~/.xine/config_xineliboutput.$(hostname)"
I can also copy a template ~/.xine/config_xineliboutput.$(hostname) file
to ~/.xine/config_xineliboutput before starting VDR, but this raises the
question : when do xineliboutput read this file (at startup, at each
config change, at channel change ?), and write to it (at config change,
shutdown ?)
This method worked OK for a few days, under strict manual control, but I
guess one client setting will eventually get read by another one,
breaking it in the process.
For the record: I'd like to add the following settings on the CLE266
clients only (these add hardware deinterlacing on a progressive VGA
display, which also work very cleanly on an interlaced TV output,
probably because xvmc_bob_deinterlacing does exactly the opposite as the
VT1622 TV encoder, ie. alternate 25Hz fields at 50Hz):
1 # Use bob as accelerated deinterlace method.
2 # bool, default: 0
3 video.device.xvmc_bob_deinterlacing:1
4
5 # Make XvMC allocate more frames for better buffering.
6 # bool, default: 0
7 video.device.xvmc_more_frames:1
TIA
--
NH
[View Less]