Hi,
I located a small bug which has been introduced in 1.7.18 (at least I think
so). Reading the Changes file I could not determine which change caused it,
but the problem is the following.
In pat.c: if the PMT of a service has a stream of stream-type 128 (0x80)
the vpid is overridden with the PID signalled in the Elementary-PID-field of
this stream. This happens to be the case here in France for some of the DVB-
T services. It breaks 2 channels (France 2 and France 5) when channel-
…
[View More]updates is at least configured to "update PIDs".
The code which is doing that is described as "STREAMTYPE_USER_PRIVATE -
DigiCipher II VIDEO (ANSI/SCTE 57)" which before was only applied when the
stream had a certain descriptor and there a certain type.
The attached patch resets the code to do exactly that for STREAMTYPE 0x80 -
though can't check whether the digiCipher-stuff is still working.
Please consider applying soon.
Thanks,
--
Patrick
http://www.kernellabs.com/
[View Less]
VDR developer version 1.7.27 is now available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.27.tar.bz2
A 'diff' against the previous version is available at
ftp://ftp.tvdr.de/vdr/Developer/vdr-1.7.26-1.7.27.diff
MD5 checksums:
bfeaa79a9e55144bca2b69139c45f1bb vdr-1.7.27.tar.bz2
b23344be51d3e2c2d96cc2dd4e8e564e vdr-1.7.26-1.7.27.diff
WARNING:
========
This is a *developer* version. Even though *I* use it in my productive
environment. I strongly recommend that you only use it …
[View More]under controlled
conditions and for testing and debugging.
The changes since version 1.7.26:
- Updated the Finnish OSD texts (thanks to Rolf Ahrenberg).
- Changed the Green button in the "Edit timer" menu from "Once" to "Single"
(suggested by Rolf Ahrenberg).
- Fixed some typos in HISTORY and CONTRIBUTORS (thanks to Ville Skyttä).
- The channel name column in the "What's on now/next" menu now adjusts its width
to display the full short name of each channel (suggested by Dominic Evans).
- Dropped the meanwhile obsolete script 'i18n-to-gettext'.
- Removed the obsolete function cPlugin::RegisterI18n().
- Removed the obsolete typedef tI18nPhrase.
- Adapted menu column widths of 'skincurses' to the wider HD OSD sizes.
- Deactivated definition of __RECORDING_H_DEPRECATED_DIRECT_MEMBER_ACCESS (recording.h)
and LEGACY_CRECEIVER (receiver.h) to trigger an error for any plugin that still
uses the respective code. You can reactivate these to quickly make your plugin
compile again, but beware that these code parts will be removed in one of the next
versions.
- Made the "overloaded-virtual" warning an error to detect hidden overloaded
virtual functions (thanks to Anssi Hannula for pointing out -Werror=...).
Plugin authors may want to change -Woverloaded-virtual to -Werror=overloaded-virtual
in their Makefiles.
- Updated the Estonian OSD texts (thanks to Arthur Konovalov).
- Improved fast forwarding to the end of a timeshift recording.
- The new function cDevice::DeviceName() returns a string identifying the name of
the given device.
- When toggling a timer between "Single" and "Repeating", the previous setting is now
retained in case the user toggles back to the original value.
- When estimating the remaining disk space (in hours), the average data rate of all
existing recordings is now taken into account. If this value can't be determined,
the previous value of 25.75 MB/min is taken.
- No longer using GetFont() (which is not thread safe) in the 'osddemo' plugin.
- No longer using GetFont() (which is not thread safe) in cSubtitleRegion::UpdateTextData().
- Fixed a memory leak in cSubtitleRegion::UpdateTextData().
- Moved setting LC_NUMERIC further up to make sure any floating point numbers use a
decimal point (suggested by Tobias Grimm).
- Added missing channel locking to cEIT.
- Fixed reduced bpp support for DVB subtitles (thanks to Rolf Ahrenberg).
- Updated the Italian OSD texts (thanks to Diego Pierotto).
- Reverted some improvements to Make.config.template (thanks to Christian Ruppert).
- Fixed handling IDLEPRIORITY in cDvbDevice::ProvidesChannel() (thanks to Frank
Schmirler).
Have fun!
Klaus
[View Less]
Slightly off topic, am about 6000 miles away, but can someone post an
updated Crystal Palace dvb-t/freeview channels.conf file. My slingbox is
acting up and, coming from a VDR background, I want to see what the
channels.conf is to work out why.
(If you're slingbox interested, the BBC Mux is missing half its channels
while the slingbox is set to UK, if I set it to Italy, I get all the
muxes/channels but no channel order). I will probably use the
channels.conf file to work out what the …
[View More]channel mapping is and leave it
on. The long term plan is to use vdr-iptv and a script to feed slingbox
input into my VDR on this side of the atlantic, just waiting for the
slingbox code in xbmc to turn into a standalone program.)
[View Less]
The new version should compile with VDR 1.7.27 and fix the issues with the
TT6400 OSD.
Special thanks in random order to Udo Richter, gda and nox from
vdrportal.de, Andreas 'powARman' Regel, Rolf Ahrenberg and Uwe
The changes:
* VDR 1.7.27 compatibility (Closes #919), Credit goes to nox and gda fro
vdrportal.de
* Instead of doing mixed drawing to cOsd and cBitmap only draw to cBitmap
(Closes #899, this should fixe the issues with the TT6400)
As always: Any help is welcome!
Development …
[View More]site:
http://projects.vdr-developer.org/projects/plg-osdteletext
Downloads:
http://projects.vdr-developer.org/projects/plg-osdteletext/files
Git-Web:
http://projects.vdr-developer.org/git/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!
Tobias
[View Less]
Freeview HD's EPG uses the same encoding as Freesat, but for some reason
the EEPG plugin doesn't recognise it; it probably only uses the extended
decoder when it's using Freesat's non-dtandard PIDs.
EEPG's code is a bit tortuous, and it has a memory leak, so I decided to
look again at the Freesat patch from <http://www.rst38.org.uk/vdr/>. It
needed a bit of updating for recent versions of VDR, and I also updated
the tables with data from the EEPG plugin.
And it works nicely :-). I haven'…
[View More]t been using it long, but it looks like
it isn't leaking, and all the text in the EPG looks correct.
I've uploaded it to
<http://www.realh.co.uk/vdr_freesat_freeviewhd.patch.gz>. If you use
Debian or Ubuntu you can add it to the source package with quilt import.
But also add this line to debian/vdr.install (I got errors after
trying to add it to the patch):
freesat.t* var/lib/vdr/
If not using debs you'll have to copy the freesat.t1 and .t2 files there
manually, or redefine FREESAT_DATA_DIRECTORY in libsi/freesat.c if you
want them to live somewhere else.
[View Less]
There are numerous patches in the debian packaging tree for yaVDR,
some of which have been naturally picked up from the standard debian
packages and some of which are yaVDR specific:
https://github.com/yavdr/vdr/tree/master/debian/patches
It is not immediately obvious which of these have been submitted to
Klaus for review, and which have been rejected from inclusion in
vanilla VDR. It would seem to be a good idea to go through all of
these and update the headers of them to indicate if …
[View More]they have either
been rejected, or are considered to be too
major/untested/plugin-specific to be included in the vanilla tree.
Debian have patch tagging guidelines which have appropriate fields
designed for this:
http://dep.debian.net/deps/dep3/
The patches already use these guidelines, with correct values for
Author, Description and sometimes Origin but just don't mention
whether the patches have been reviewed/rejected etc.
Ideally we'd go through all of these and add the 'Forwarded' tag to
either link to the mailing list thread where the patch has been
submitted to Klaus, or setting it to 'Forwarded: not-needed' for
patches that we know don't make sense to include in vanilla VDR (e.g.,
plugin specific etc.). Any patches that have previously been rejected
would also have an appropriate message appended to their description
field to indicate they had been rejected and for what reason (as per
the example on the above dep3 link).
As a first glance, there are a few small patches that it would seem
could be submitted to Klaus:
https://github.com/yavdr/vdr/blob/master/debian/patches/opt-29_syncearly.pa…https://github.com/yavdr/vdr/blob/master/debian/patches/opt-43-x_recordshow…https://github.com/yavdr/vdr/blob/master/debian/patches/opt-24_jumpplay.pat…
Before I rebase these as patches against the latest vanilla sources
and submit them on the mailing list, does anyone know if these have
previously been submitted, either by their authors (if still active),
or a current maintainer?
[View Less]
Quick data points with Finnish YLE DVB subtitles, using a dxr3:
1.7.22: everything works
(never tried versions between here, because I was stuck with a 2.6 kernel
back then)
1.7.25: subtitles are almost black and thus illegible
1.7.26: same thing
1.7.27: colours OK, but during live programming, maybe one of every 20
subtitles shows at all, and are about half the correct size. Same thing
when viewing recordings made with this version - when I replay old
recordings, all subtitles seem to get …
[View More]displayed.
vdr-dxr3-plugin version 0.2.13 from here:
http://projects.vdr-developer.org/projects/plg-dxr3/files
em8300 drivers from here (cloned on March 17th, I think):
hg clone http://dxr3.hg.sourceforge.net:8000/hgroot/dxr3/em8300 dxr3
System Ubuntu Oneiric, kernel 3.0.0-17 from Ubuntu sources (but
recompiled by myself, because those nice folks at Ubuntu had to turn
OSS support off in the kernel, preventing the em8300 drivers from
working)
--mika
[View Less]
I recently updated from 1.7.22 to the latest VDR developer snapshot 1.7.27
My DVB-S/DVB-S2 tuners all continued to work fine, but none of my
DVB-T channels were accesible anymore.
Checking the logs I noticed numerous "ERROR: invalid value for
parameter 'S'" entries, whenever attempting to tune to a DVB-T
channel. I presumed this was related to the changes introduced into
1.7.23 for not writing values to channels.conf that weren't valid for
the given delivery system, but I couldn't find …
[View More]anything in the
Changelog that indicated a channels.conf change was needed.
I guessed the simplest way to fix this was to use VDR's channel editor
to 'edit' and save my DVB-T channels, without modifying anything, and
seeing what change was introduced in channels.conf
- ITV1:642000000:B8C23D12G32M64:T:0:520=2:521=eng@3,522=eng@3:0;523=eng:0:8271:9018:8207:0
+ ITV1:642000000:B8C23D12G32M64S0T8Y0:T:0:520=2:521=eng@3,522=eng@3:0;523=eng:0:8271:9018:8207:0
It is trivial for me to reproduce this for all my channels. However, I
presume this means that scan / w_scan etc. all need to be updated to
generate the new channels.conf format for VDR 1.7.23 and newer?
[View Less]