Re: [vdr] VDR form packages
On Tue, 08 May 2012 20:29:13 +0200 Tobi wrote: > On 08.05.2012 18:34, Marx wrote > > > I didn't know and that's why his repository isn't updated. In fact I use > > lately Debian's version (and I was quite suprised that so new version is > > available in Debian). Hovewer number of available plugins in Debian is > > pretty low. Do you know if he plans to migrate more of them to Debian? > > Make some suggestions what Plugins you would like to see in official > Debian! I'm going to upload markad to Debian soon. I'd like eepg to be packaged, but only if the memory leak can be fixed and it's made to work on Freeview HD. The Huffman tables and marker bytes at the start of the strings are the same as for Freesat so it just needs changing to apply this decoding to the standard EIT pids if necessary, not only to Freesat's pids. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0
Hi, On 05/08/2012 07:30 PM, Marx wrote: because I see no changes in EPG whatever I put in /etc/vdr/plugins/charset.conf Marx I may be way off the mark here - I have come in halfway through the thread and do not use this plugin, but wouldn't the path above be: /etc/vdr/plugins/epgfixer/charset.conf ? Regards, Richard ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0
On 05/08/2012 07:30 PM, Marx wrote: VDR isn't as popular here in Poland as in Germany, so I doubt anyone in Cyfra+ know what VDR is. Anyway I've tried ISO-8859-9 in epgfixer, but nothing has changed. Next is ISO-8859-2 but I'm afraid that I'm configuring something bad because I see no changes in EPG whatever I put in /etc/vdr/plugins/charset.conf Marx I don't know why you don't see any changes in EPG data if you change the config since I do, although not the correct characters. I just noticed that due to internal conversion from assumed ISO6937 to whatever your VDR is using causes problem, but these can be circumvented by first reverting VDR's conversion i.e back to ISO6937 and then from for example ISO-8859-9 to VDR's charset. Unfortunately this is not yet possible in the plugin but I have already made the necessary code to fix the problem. I will try to release a new version hopefully tomorrow. I have also found several other bugs which I will fix before a new release. I have also some new features that I try to include. -- Matti ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On Tue, May 8, 2012 at 11:29 AM, Tobi wrote: > Make some suggestions what Plugins you would like to see in official Debian! > I'm going to upload markad to Debian soon. If you haven't added it already, you should consider adding softhddevice. People have wanted an alternative to the xinelib-based options (vdr-xine, xineliboutput) and this newish plugin offers just that. It currently supports vdpau, with more coming (although most users seem to only use vdpau or software decoding anyways). It also supports toggling between stereo mixdown and surround sound without restarting anything which I love as a feature. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0
As written earlier I'm packaging this plugin in my vdr repository for openSUSE. But I have a ploblem using the plugin, I got this at start: vdr: /usr/lib64/vdr/libvdr-epgfixer.so.1.7.27: undefined symbol: pcre_free The plugin is building without problems. Has anybody any idea how I can fix this? :) Am Samstag, 5. Mai 2012 schrieb Matti Lehtimäki : > New features in 0.1.0: > - Support for character set conversion for selected channels. > - Support for stripping HTML entities. > - Supply user with extra information for each setup menu option using > Info key. > > Homepage for the plugin: > http://projects.vdr-developer.org/projects/plg-epgfixer > > -- > Matti > > ___ > vdr mailing list > vdr@linuxtv.org > http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On 08.05.2012 18:34, Marx wrote I didn't know and that's why his repository isn't updated. In fact I use lately Debian's version (and I was quite suprised that so new version is available in Debian). Hovewer number of available plugins in Debian is pretty low. Do you know if he plans to migrate more of them to Debian? Make some suggestions what Plugins you would like to see in official Debian! I'm going to upload markad to Debian soon. And my e-tobi.net-repository has been updated this morning. But there are some old plugins with no upstream activity that I haven't migrated to VDR 1.7.27 yet. I will do this on request (just drop me a mail) and will drop the remaining plugins if nobody misses them. Tobias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On Tue, May 8, 2012 at 9:45 AM, Marx wrote: > I'm not as good in writing scripts as you :) Do you install VDR from > sources, or build debian packages? Scripting is really easy once you know it. If not, no worries, it's easy to learn too. :) When I first started with VDR, I installed it. Then I switched to building debian packages at one point. Later I realized it was useless for me to bother installing/using packages and I just compile & run it from it's source dir. I have a /vdr symlink which I always point to whichever source dir I want to use to `cd /vdr` always gets me to the current source dir, or `/vdr/vdr` always runs my current VDR. For me it just didn't make sense to have plugins here, VDR binary there, settings over there, other data over here.. But the great part is everyone can configure it however they like! > I know it's not so hard to build everything manually and in fact I did it > many times. Hovewer packages in yavdr or e-tobi repositories were easier to > install, and it was sure they will work together. Sometimes VDR or packages > are patched to work better by maintainer of repo. I don't need to follow all > git svn of all plugins and cope with some problems of compiling it myself, > if somebody did it. I think it's better to use his work because it's better > in it and additionally i test his work. Sometimes I'm in hurry to test some > "super new plugin". Aptitude, search, install, restart vdr and test - it > gets a few minutes and afterall it's easy to unistall it too. And while new > version of VDR is published, i simple aptitude, update and go - I have new > version with all new plugins. > That's why I like having VDR in packages. > Knowing that Debian has "master od VDR" ;) in his team is very good info and > I will try to stick with this version Those repositories are definitely a good choice for some people. At the end of the day, people seem to prefer `plug & play` solutions. I don't bother with them mostly because they have a ton of junk I don't need/want patched in, and they don't support all the NA needs as far as I know (maybe it has changed now). I also like to test VDR & plugins so _for me_ working with source is the best in case I need to edit something for testing purposes. I give the same advice for VDR as I do with any software in general -- just pick what works best for your needs/wants. There's some software I'd much rather apt-get than compile myself. :) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0
W dniu 2012-05-08 17:02, VDR User pisze: On Tue, May 8, 2012 at 6:14 AM, Hanno Zulla wrote: This broadcaster (Cyfra+) sells own decoders which works, so i doubt it will fix it for a few persons using VDR :) but of course I can try do mail them. Do try. I made the experience that some engineers at these broadcasters even use VDR at home or know folks who do, so they are grateful for information like that. If they use VDR at home, how come they didn't know their epg was broken? VDR isn't as popular here in Poland as in Germany, so I doubt anyone in Cyfra+ know what VDR is. Anyway I've tried ISO-8859-9 in epgfixer, but nothing has changed. Next is ISO-8859-2 but I'm afraid that I'm configuring something bad because I see no changes in EPG whatever I put in /etc/vdr/plugins/charset.conf Marx ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
I'm not as good in writing scripts as you :) Do you install VDR from sources, or build debian packages? I know it's not so hard to build everything manually and in fact I did it many times. Hovewer packages in yavdr or e-tobi repositories were easier to install, and it was sure they will work together. Sometimes VDR or packages are patched to work better by maintainer of repo. I don't need to follow all git svn of all plugins and cope with some problems of compiling it myself, if somebody did it. I think it's better to use his work because it's better in it and additionally i test his work. Sometimes I'm in hurry to test some "super new plugin". Aptitude, search, install, restart vdr and test - it gets a few minutes and afterall it's easy to unistall it too. And while new version of VDR is published, i simple aptitude, update and go - I have new version with all new plugins. That's why I like having VDR in packages. Knowing that Debian has "master od VDR" ;) in his team is very good info and I will try to stick with this version Marx ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
W dniu 2012-05-08 16:10, Pertti Kosunen pisze: On 8.5.2012 15:16, Marx wrote: This lead to alternative repositories. I know two valuable: e-tobi and yavdr. I was using e-tobi but it lately isn't updated to the newest VDR. http://qa.debian.org/developer.php?login=et...@debian.org http://packages.qa.debian.org/v/vdr.html Tobias Grimm is now in official Debian team. http://packages.debian.org/search?searchon=names&keywords=vdr Sid and testing have pretty new versions. I didn't know and that's why his repository isn't updated. In fact I use lately Debian's version (and I was quite suprised that so new version is available in Debian). Hovewer number of available plugins in Debian is pretty low. Do you know if he plans to migrate more of them to Debian? Marx ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0
On Tue, May 8, 2012 at 6:14 AM, Hanno Zulla wrote: >> This broadcaster (Cyfra+) sells own decoders which works, so i doubt it >> will fix it for a few persons using VDR :) but of course I can try do >> mail them. > > Do try. I made the experience that some engineers at these broadcasters > even use VDR at home or know folks who do, so they are grateful for > information like that. If they use VDR at home, how come they didn't know their epg was broken? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On Tue, May 8, 2012 at 5:16 AM, Marx wrote: > Hello > I use Debian for years and to keep it clean I'm trying to use all software > from packages. It generally works, hovewer I have problem with VDR, XBMC and > drivers. > Usually to have the newest driver I need to use some unstable version of VDR > with the newest possible kernel. > VDR in Debian is an option, hovewer it's usually behind the newest VDR, and > number of plugins in repository is low. > This lead to alternative repositories. I know two valuable: e-tobi and > yavdr. I was using e-tobi but it lately isn't updated to the newest VDR. > Yavdr is built on top of Ubuntu, and while it generally works on Debian, > it's not recommended (some things doesn't work). > So there is an option to build packages myself - really no option, because I > have to make package manually for every plugin and for every new version of > VDR. > Any idea? Why don't you just write a script that automates it all for you. If it encounters an error along the way, just abort and report the error to the user. Building VDR and plugins from source is very easy assuming you don't bother with tons of patches (which can break things quickly). It's also very easy to add in support for updating the kernel, media_build drivers, nvidia drivers, etc.. This is exactly what I did and I almost never have to actually do anything by hand anymore -- just select what I want from my menu and it magically happens. ;) ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
On 8.5.2012 15:16, Marx wrote: This lead to alternative repositories. I know two valuable: e-tobi and yavdr. I was using e-tobi but it lately isn't updated to the newest VDR. http://qa.debian.org/developer.php?login=et...@debian.org http://packages.qa.debian.org/v/vdr.html Tobias Grimm is now in official Debian team. http://packages.debian.org/search?searchon=names&keywords=vdr Sid and testing have pretty new versions. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR form packages
Am 2012-05-08 14:16, schrieb Marx: Hello I use Debian for years and to keep it clean I'm trying to use all software from packages. It generally works, hovewer I have problem with VDR, XBMC and drivers. Usually to have the newest driver I need to use some unstable version of VDR with the newest possible kernel. VDR in Debian is an option, hovewer it's usually behind the newest VDR, and number of plugins in repository is low. This lead to alternative repositories. I know two valuable: e-tobi and yavdr. I was using e-tobi but it lately isn't updated to the newest VDR. Yavdr is built on top of Ubuntu, and while it generally works on Debian, it's not recommended (some things doesn't work). So there is an option to build packages myself - really no option, because I have to make package manually for every plugin and for every new version of VDR. Any idea? Any idea to what? Your have not asked any questions. What do you want to know? Gerald ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0
Hi, > This broadcaster (Cyfra+) sells own decoders which works, so i doubt it > will fix it for a few persons using VDR :) but of course I can try do > mail them. Do try. I made the experience that some engineers at these broadcasters even use VDR at home or know folks who do, so they are grateful for information like that. Regards, Hanno ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] VDR form packages
Hello I use Debian for years and to keep it clean I'm trying to use all software from packages. It generally works, hovewer I have problem with VDR, XBMC and drivers. Usually to have the newest driver I need to use some unstable version of VDR with the newest possible kernel. VDR in Debian is an option, hovewer it's usually behind the newest VDR, and number of plugins in repository is low. This lead to alternative repositories. I know two valuable: e-tobi and yavdr. I was using e-tobi but it lately isn't updated to the newest VDR. Yavdr is built on top of Ubuntu, and while it generally works on Debian, it's not recommended (some things doesn't work). So there is an option to build packages myself - really no option, because I have to make package manually for every plugin and for every new version of VDR. Any idea? Marx ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0
On 8 May 2012 12:36, Marx wrote: > On 08.05.2012 10:11, Klaus Schmidinger wrote: >> >> Has anybody ever tried to contact the broadcaster who is sending this >> broken EPG >> data, and ask them to fix it? >> Might be worth a try... > > > This broadcaster (Cyfra+) sells own decoders which works, so i doubt it will > fix it for a few persons using VDR :) but of course I can try do mail them. > But first I would like to understand which codepage this EPG use. File > /var/cache/vdr/epg.data narrowed to only this channel doesn't seem to use > any standard codepage > Marx There are numerous defects raised for Cyfra+ over the web against other PVRs (MythTV, Tvheadend etc.). A quick google seemed to suggest the following encodings are used on Cyfra+: ISO-8859-2 for source network id 113 ISO-6937 for source network id 318 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0
On 08.05.2012 10:11, Klaus Schmidinger wrote: Has anybody ever tried to contact the broadcaster who is sending this broken EPG data, and ask them to fix it? Might be worth a try... This broadcaster (Cyfra+) sells own decoders which works, so i doubt it will fix it for a few persons using VDR :) but of course I can try do mail them. But first I would like to understand which codepage this EPG use. File /var/cache/vdr/epg.data narrowed to only this channel doesn't seem to use any standard codepage Marx ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] LNB sharing interrupts recordings with Twinhan DVBS
On 07.05.2012 14:34, Midas wrote: Am 06.05.2012 12:20, schrieb Klaus Schmidinger: On 06.05.2012 11:59, Midas wrote: Am 06.05.2012 11:51, schrieb Klaus Schmidinger: On 06.05.2012 01:29, Midas wrote: Am 05.05.2012 16:31, schrieb Klaus Schmidinger: On 05.05.2012 09:22, Midas wrote: Hi there, i have two satellite devices in an lnb-sharing setup. As said in the topic since update to vdr 1.7.27 recordings do not put data on the disk anymore and AV liveview with the vdr-sxfe frontend freezes if bonding sets the Twinhan Card to master. The setup is Technisat Skystar HD and KWorld DVBS Satellite Card (clone of Twinhan VP1020), so it is DVBS2 and DVBS mixed. VDR is 1.7.27. I have been using vdr 1.7.21 before with lnb-sharing applied. In the old setup there was a similar problem in that switching to vertical didn't work reliably or at all respectively. I managed to overcome this behaviour by patching the Twinhan driver to eliminate _any_ voltage output on the card. Once i found a working patch vdr has been running for months without any problems anymore. Note that the 'new' issue occurs with the vanilla Twinhan driver and my patched version as well. Is it maybe possible to force the use of one card as Master bonding device or does anyone have other ideas to overcome the problems? If the master of a set of bonded devices doesn't get a signal, VDR should automatically switch the master to the next of the bonded devices. See cDvbTuner::Action(), case tsTuned: if (bondedTuner&&bondedMaster) bondedMasterFailed = true; // give an other tuner a chance in case the sat cable was disconnected Of course, making sure the devices work properly in the first place might be a good idea ;-) Do i get the term Master wrong? Master in my assumption should be the device where the liveview signal comes from unless there is a recording in which case the device tuned to the recording transponder should be Master. In the context of device bonding "master" means the device that actually controls the LNB (either trough voltage/tone or DiSEqC). It has nothing to do with whether this device is used for live view or recording. In the first case the slave cannot steal the tuning parameters to prevent breaking liveview whereas in the second the liveview slave cannot interefere with the ongoing recording. Concerning my issue the ongoing search for transponders on the non-liveview device seems to break with the liveview device which should not happen. Yet in case of recordings i am bit unsure what interferes with what. I am also still unsure if it is a driver or lnb sharing issue though the v/h issue in my former setup points to the first case at least for a certain kind. Do i conclude right, setting the bondedMasterFailed to false in the switch construct would be a dirty hack to workaround my bogus setup? I'm not sure about that. I would suggest you use VDR with only one single device at a time and make sure it can receive all polarizations and bands. If a device or driver fails to deliver that, you should try to fix it. VDR assumes that a device actually works ;-) Just to add this missing info: Both devices work perfectly in a single device setup. Both devices were even capable in the former 1.7.21 dual device setup (with my patch). Well, then please post your exact setup together with a step-by-step set of instructions on how to reproduce the problem. Maybe I can reproduce it here on my system. Klaus Thank you Klaus for your offer and your effort. I guess this is one of the bugs (not necessarily a vdr one!) which are relativley hard to track. Yesterday i have reproduced the issue with a vanilla vdr 1.7.27 and the only plugin being xineliboutput to minimize potential bug sources. I did not observe any changes, the issue still appears. My setup: debian squeeze self-built Kernel 3.0.4 media-build git20120504 vdr 1.7.27 Technisat Skystar HD (PCI DVB-S2) -> clone of and recognized as Technotrend S-3200 (stb0899) KWorld DVB Satellite card -> clone of Twinhan VP1020 (PCI DVB-S) WinTV Nova T-Stick (USB DVB-T) xineliboutput cvs20120415 vdr-sxfe with vdpau on a 8400 GS PCIE nvidia driver 295.40 Satellite setup: One satellite cable that is being distributed with a splitter (diode protected). No priority circuit afaik. In vdr both devices are set to be connected to cable 1. This is a Diseqc setup and Astra 19.2E and Hotbird 13.0E are receivable. The rest of the setup remains unclear yet most likely the cable goes to a switch or something though surely not directly into the lnb. Symptoms: AV signal sometimes stops while watching a DVB-S(2) channel (T not tested). Concerning the log this most likely happens when vdr fails to tune to a channel while scanning for new transponders in the background. Device bonding then tries to make another tuner tune to this channel which in this case obviously is the liveview device. This not only freezes the liveview AV but also makes recordings stop to write data on
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0
On 08.05.2012 08:27, Marx wrote: On 07.05.2012 18:10, Matti Lehtimäki wrote: There is no need to activate the plugin or fixes through OSD. Everything can be done also by just using config files. good news I'll add some logging about active fixes to next version. One thing that comes to mind is the need to clear EPG data. The plugin only fixes new EPG data not the already existing data. So before you can see if the conversion works you need to clear old data. You can do that either by manually deleting epg.data, using VDR SVDRP command CLRE or by using this plugin's setup menu. I'm of course cleaning epg every time I'm testing by deleting /var/cache/vdr/epg.data. I will wait for a version with more logs. 4) I use UTF-8 in system. I have problem how to recognize charset of epg on this channel. I was trying to parse /var/cache/vdr/epg.data but it seems that encoding is broken. Seems like some polish characters are saved on 2 chars (UTF), but it's not proper pair to create polish character. So instead of: 100 tysięcy bocianów I'm getting: 100 tysiЮecy bocianТow I don't know anything about that kind of problem. The problem is that probably codepage which I'm trying convert from is not really iso6937. As stated by Klaus in other threads, if provider doesn't broadcast codepage, standard says it's iso6937. If provider broadcast codepage - VDR convert it automatically and it works without any additional steps. Tests to use epgfixer with converting from iso6937 do nothing - EPG is still broken. So probably iso6937 is not codepage which I had to try to convert from (it's logical - if it really would be iso6937 - VDR would convert it because it's standard). Hence the need to determine in which codepage this EPG is really broadcasted. I was trying "konwert" on epg.data file but no luck. While it suggests a few codepages none of them is usable on that file (converting to thic codepages didn't fix this file). So probably this file has completely messed up encoding which can't be converted. I guess that VDR uses encoding from my system properties - UTF 8. It somehow tries to convert this EPG and fails, yet still save it in UTF-8 which and then file becomes messed up. Another possibility is that this EPG isn't any standard codepage, and so I have to write some regexp to mimic this patch http://pastebin.com/tkNtpTCh I've just read closer this patch and it's different from what I have used prevoiusly and suggest to try ISO-8859-9. I will try it. Has anybody ever tried to contact the broadcaster who is sending this broken EPG data, and ask them to fix it? Might be worth a try... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] epgfixer-plugin 0.1.0
On 07.05.2012 18:10, Matti Lehtimäki wrote: There is no need to activate the plugin or fixes through OSD. Everything can be done also by just using config files. good news I'll add some logging about active fixes to next version. One thing that comes to mind is the need to clear EPG data. The plugin only fixes new EPG data not the already existing data. So before you can see if the conversion works you need to clear old data. You can do that either by manually deleting epg.data, using VDR SVDRP command CLRE or by using this plugin's setup menu. I'm of course cleaning epg every time I'm testing by deleting /var/cache/vdr/epg.data. I will wait for a version with more logs. 4) I use UTF-8 in system. I have problem how to recognize charset of epg on this channel. I was trying to parse /var/cache/vdr/epg.data but it seems that encoding is broken. Seems like some polish characters are saved on 2 chars (UTF), but it's not proper pair to create polish character. So instead of: 100 tysięcy bocianów I'm getting: 100 tysiЮecy bocianТow I don't know anything about that kind of problem. The problem is that probably codepage which I'm trying convert from is not really iso6937. As stated by Klaus in other threads, if provider doesn't broadcast codepage, standard says it's iso6937. If provider broadcast codepage - VDR convert it automatically and it works without any additional steps. Tests to use epgfixer with converting from iso6937 do nothing - EPG is still broken. So probably iso6937 is not codepage which I had to try to convert from (it's logical - if it really would be iso6937 - VDR would convert it because it's standard). Hence the need to determine in which codepage this EPG is really broadcasted. I was trying "konwert" on epg.data file but no luck. While it suggests a few codepages none of them is usable on that file (converting to thic codepages didn't fix this file). So probably this file has completely messed up encoding which can't be converted. I guess that VDR uses encoding from my system properties - UTF 8. It somehow tries to convert this EPG and fails, yet still save it in UTF-8 which and then file becomes messed up. Another possibility is that this EPG isn't any standard codepage, and so I have to write some regexp to mimic this patch http://pastebin.com/tkNtpTCh I've just read closer this patch and it's different from what I have used prevoiusly and suggest to try ISO-8859-9. I will try it. Marx ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
