Hi,
I wrote a patch to Steve Toth hvr3000 repository, so my FlyDVB Trio can use
multiple frontend.
So I get:
/dev/dvb/adapter0/demux0
/dev/dvb/adapter0/demux1
/dev/dvb/adapter0/dvr0
/dev/dvb/adapter0/dvr1
/dev/dvb/adapter0/frontend0
/dev/dvb/adapter0/frontend1
/dev/dvb/adapter0/net0
/dev/dvb/adapter0/net1
The bus of the two frontend is shared, isn't possible to get access to both
frontend simultaneously, so I get an -EBUSY error by trying accessing
frontend1 if frontend0 is …
[View More]in use.
VDR doesn't support yet the second frontend, and it try to get exclusive
access on both frontend on start, so the second frontend is inusabile.
Vdr should probe for multiple frontend at start, and access frontend only on
channel change.
Please can someone give me an help to wrote a patch for this issue?
Best Regards,
Eddi
[View Less]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello list.
As the subject already says, this is about VDR portability, or how to get
VDR up and running on a FreeBSD system.
In times where we have such really nice plugins like softdevice and
streamdev, we no longer need real MPEG2 or DVB hardware in a VDR system.
As i want to use my FreeBSD systems to watch TV or play VDR recordings i
decided to give porting VDR to FreeBSD a try.
Attached you can find the results.
In short terms: It simply …
[View More]works!
The only missing feature right now is, starting VDR as root and switching
to another user (-u command line option).
For now it is possible to watch any recording made by a VDR with real
hardware if the video directory is directly accessible over the network
(mountable by the client) or the use the streamdev plugin to stream VDR to
VDR.
All tests where done using a Linux system with two FF-DVB-S devices,
streamdev-server plugin and NFS exported video directory plus a wired and
a wireless FreeBSD-7.0 client running VDR with streamdev-client and
softdevice plugin.
As far as i could test the whole setup until now, everything works the
same way on FreeBSD as it does under Linux and i now have real
channel-hopping.
The patches are made in a way that a patched VDR will still compile under
Linux. Every modification, to the source or to the Makefiles is ifdef'd
out. So unless you say you want to compile VDR for FreeBSD you have an
unmodified version of source.
In case the ML software strips the attachments, the files are also
available for download at: ftp://ftp.frm2.tum.de/pub/jpulz/VDR/
Thoughts or comments from others are welcome.
regards
Joerg
- --
The beginning is the most important part of the work.
-Plato
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
iD8DBQFH0Dy8SPOsGF+KA+MRAmVBAJ9Tzfxg0zWNN/fEX8vfeMOW2muvSACgivha
raTzC4R92jZ+Petp9Mqwr9E=
=f08n
-----END PGP SIGNATURE-----
[View Less]
El Viernes, 13 de Marzo de 2009, H. Langos escribió:
> Hi,
>
> I just installed vdr and vdradmin-am on Debian lenny and it seems that two
> years down the road the problem still exists. (Though in a more subtle way)
>
> I even tried the 3.6.4-1 from debian testing and still the pages have
> this in the head section:
>
> meta http-equiv="content-type" content="text/html;charset=ISO-8859-1"
>
> My system default locale is en_US.UTF-8
> # cat /etc/default/…
[View More]locale
> LANG="en_US.UTF-8"
>
> Only switching to something like de_DE.UTF-8 seems to fix the problem.
> Seems like gettext('ISO-8859-1') is not the best way of handling
> encodings after all.
>
> Anyway, isn't it time to make a move towards a default UTF-8?
>
> cheers
> -henrik
>
> PS: I'm not subscribed to vdr or vdradmin-am. So please CC me.
In my case the problem is that the directory where the UTF8 locale is stored
is:
/usr/share/locale/es_ES.utf8/
if I change to:
/usr/share/locale/es_ES.UTF8
All work ok.
Jose Alberto
>
> On Thu, Jan 01, 1970 at 12:00:00AM +0000, Jose Alberto Reguero wrote:
> > El Mi?rcoles, 28 de Marzo de 2007, Lucian Muresan escribi?:
> > > Jose Alberto Reguero wrote:
> > > > El Martes, 27 de Marzo de 2007, Harald Milz escribi?:
> > > >> Hi,
> > > >>
> > > >> is anyone working on a UTF-8 version of VDRadmin-AM? I'm using vdr
> > > >> with the UTF8 patch (de and ru) and need to always select UTF8
> > > >> manually in the browser to avoid seeing the ? stuff. Looking at the
> > > >> html files in template/default/, I see everything is hardcoded in
> > > >> iso-8859-1, but that should be a configuration option. Setting
> > > >> LANG=de_DE.utf8 doesn't help, it is silently ignored.
> > > >>
> > > >> Anyone?
> > > >>
> > > >> THX.
> > > >
> > > > I run:
> > > >
> > > > sed -i -e s/ISO-8859-1/UTF-8/g *.html
> > > >
> > > > in the template/default/ directory.
> > >
> > > Andreas Mair already adopted my UTF-8 patch for the vdradmin locales,
> > > months and versions ago. It patches the makefile and adds targets for
> > > generating the UTF-8 locales out of the stock ones. For more info,
> > > check this thread:
> > > http://www.linuxtv.org/pipermail/vdr/2006-July/010116.html
> > >
> > > Regards,
> > > Lucian
> >
> > I use make.sh utf8add and make.sh po but the html files in
> > template/default/ still have references to ISO-8859-1, as Harald Milz
> > says, and firefox put the encoding to ISO-8859-1. That is with
> > vdradmin-am-3.5.3.
> >
> > Jose Alberto
[View Less]
I've just moved to the US from Europe and trying to get my head around
ATSC. I have a Hauppauge HVR950q which works in Windoze and Linux (With
Kaffeine) and almost with VDR (my preferred platform).
I have it normally connected to Comcast cable which should pipe through
a bunch of FTV channels using QAM256. These I can see and hear in
kaffeine with AC97 audio. However, in VDR it appears to change the pids
automatically so that the audio stops working. If I manually change VDR
to not auto …
[View More]update and put the APID in then it squeeks rather than
works. However, streaming to mplayer using streamdev seems to work. (It
does the same this with OTA channels too - although I can only get 4
with a portable antenna.)
I am using Ubuntu's VDR source 1.6.0 something or other, but patched
with the ATSC patch.
I had a really hard time trying to work out the channels.conf file, and
in the end settled for something like:
WIFR-Wx�;(null):495000:M256:C:0:1984:0:0:0:2:0:0:0
WQRF-DT�;(null):495000:M256:C:0:2048:0:0:0:3:0:0:0
WIFR-HD�;(null):495000:M256:C:0:2112:0:0:0:1:0:0:0
This is after VDR has eaten the audio pid away. Normally this is one
number higher than the vpid. So for WIFR 1985, WQRF 2049 etc.
I'm willing to believe I've cocked it up as nothing I had would
automatically scan the QAM channels. In the end I used scan and it added
"VDR Doesn't support ATSC yet" instead of M256:C:0.
Thanks guys... Fairly soon my shipping will arrive from Italy with my
main server, sat cards and Hauppauge MVP's to stick around the house. I
wonder what could possibly go wrong?
[View Less]
Hi there,
since vdr-1.7.3, VDR is compiled with the additional arguments
-D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
Plugins should be compiled with the same arguments as otherwise one might get
unresolved symbols when loading the plugin. Consistently, in vdr-1.7.4 these
defines have been added to the plugin part of Make.config.template. But that
won't fix anything for the people who don't use a Make.config at all (those
who do, need to check if something has changed in …
[View More]the template when updating).
How could this problem be solved conveniently?
I'd opt for copying Make.config.template to Make.config if no Make.config
exists yet. A good place to do this would be in "make include-dir". The
documentation and UPDATE files should remind those who copy Make.config from
an older release to fit in necessary changes.
Other options:
* Additional file to include by VDR and plugin Makefiles with such "mandatory"
defines - this somewhat contradicts the idea of Make.config.
* In the Makefile of each affected plugin, check for the presence of
Make.config. If it's missing, check the VDR version and if required, add the
defines - naah!
Cheers,
Frank
[View Less]
VDR developer version 1.7.8 is now available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.8.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.cadsoft.de/vdr/Developer/vdr-1.7.7-1.7.8.diff
WARNING:
========
This is a *developer* version. Even though *I* use it in my productive
environment. I strongly recommend that you only use it under controlled
conditions and for testing and debugging.
IMPORTANT:
==========
If you use a full featured DVB card for …
[View More]replay you need the DVB driver
version from
http://linuxtv.org/hg/v4l-dvb
in order to replay TS recordings!
Users of full featured DVB cards also need to use a new firmware,
available at
http://www.escape-edv.de/endriss/firmware
The changes since version 1.7.7:
- The name of the function cDevice::GetVideoSize() wasn't very well chosen
for its purpose of defining the optimum size of the OSD for the current
output device. Therefore a new function named cDevice::GetOsdSize() has
been introduced (suggested by Rolf Ahrenberg). Plugin authors should
implement this function in classes derived from cDevice, if they are able
to replay video. cDevice::GetVideoSize() still exists and should return the
actual size of the video material that is currently replayed. Note that
because of the many possible aspect ratios for video material, the type
of the Aspect parameter of GetVideoSize() has been changed to 'double',
and the Aspect parameter in both functions is named differently, because
it returns different values (suggested by Reinhard Nissl).
Thanks to Oliver Endriss for his input on calculating the Aspect factor in
GetOsdSize().
- Fixed the way the OSD size is determined on full featured DVB cards (thanks
to Oliver Endriss).
- Increased MAXOSDHEIGHT to 1200 (suggested by Nicolas Huillard).
- Removed limitation to PAL resolution from SPU handling.
- Checking fd_video in cDvbDevice::GetVideoSize() to avoid error messages on
systems with no real primary replay device (reported by Martin Neuditschko).
- Added a note to cTsToPes::GetPes() about having to call it repeatedly, once
it has returned a non-NULL value.
- Added MPEG 1 handling to remux.c (thanks to Ales Jurik).
- Fixed use of time_t in cEIT::cEIT() (thanks to Tobias Bratfisch).
- Added missing update of lastOsdSizeUpdate.
- EIT events are now only processed if a plausible system time is available, to
avoid wrong handling of PDC descriptors (thanks to Tobias Bratfisch).
- Removed unused 'synced' member from cTsToPes (reported by Christoph Haubrich).
- Added a note to cTsToPes about all TS packets having to belong to the same PID,
and that for video data GetPes() may only be called if the next TS packet that
will be given to PutTs() has the "payload start" flag set (suggested by Christoph
Haubrich).
- Added a note about the meaning of PERCENTAGEDELTA in cRingBuffer::UpdatePercentage()
(thanks to Rolf Ahrenberg).
- The new setup option "Recording/Pause key handling" can be used to define
what happens if the Pause key on the remote control is pressed during
live tv (thanks to Timo Eskola).
- Added a note about cFont::GetFont() not being thread-safe.
- Fixed generating PAT/PMT version numbers in case the PIDs change during
recording (reported by Reinhard Nissl).
- Updated the Ukrainian OSD texts (thanks to Yarema Aka Knedlyk).
- Fixed a memory leak when reaching the end of a recording during replay (reported
by Reinhard Nissl).
- Fixed calling close(-1) in cUnbufferedFile::Close() (reported by Reinhard Nissl).
- Added a workaround for the broken linux-dvb driver header files (based on a patch
from Tobias Grimm).
- Fixed handling the length of DiSEqC command sequences (reported by Reinhard Nissl).
- Fixed cOsdMenu::Display() in case the menu size has changed (thanks to
Reinhard Nissl).
- Added some missing 'const' keywords to avoid compilation errors with gcc 4.4
(thanks to Ville Skyttä and Ludwig Nussel).
- Modified cSVDRP::CmdGRAB() to avoid writing into const data (reported by
Ludwig Nussel).
- Fixed calculating menu colum widths in case the font has a size other than the
default size (reported by Reinhard Nissl).
- Added a plausibility check for the OSD percentage parameters
to avoid problems in case the values are stored in the setup.conf
file in a wrong way.
- Fixed variable types in cIndexFile (reported by Udo Richter).
Have fun!
Klaus
[View Less]
Hi, i have vdr178 on ubuntu 9.04. with HVR4000 i can see DVB-S and DVB-S2 channels, but not DVB-T channels.
How to configure vdr to using multiple frontends of this card pls ?
Thank you.