Re: [vdr] problems with playback and plugins with vdr-1.7.22
On Sat, 7 Jan 2012, René wrote: Then i got an other problem. When watching a recording, and i fastforward of rewind the program, i get to a situation that the timecounter get's stuck to the frame i start from. The film moves, but when i hit play, i end up back to the frame from where i started to rewind/fastforwad. The only way to fix this is to jump with the yellow/green buttons. AFter this i can rewind/fastforwad normally. This again works for a while, but again if it fails to stop to the place i rewind to, i have to reset the rewind-issue with the yellow/green buttons... Is this a known bug in vdr, or is it something that i have messed up in my setup? I was under impression that this is already fixed in xineliboutput 10.12.2011 or newer. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] vdr-1.7.21 DVB-T2 support
On Thu, 22 Dec 2011, Stuart Morris wrote: I'm running 1.7.21 with a DVB-T and DVB-T2. The only patch I have is for decoding the compressed EPG for UK Freeview HD. Does DVB-T2 need special handling in VDR? That's not been my experience. I suspect it depends on the tuner driver. I'm using a PCTV nanoStick 290e. Well, your T2 channels are most propably using PLP id 0 and your driver is defaulting to that one, so your working setup is pure luck until the broadcasting systems are getting more complex :) Also without the patch there's no mechanism to prevent your DVB-T cards tuning to DVB-T2 channels. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] vdr-1.7.21 DVB-T2 support
No comments? Am I really the only one running such a DVB-T + DVB-T2 system? Anyway, this has worked quite nicely for a rather long time on my setup, and therefore I strongly suggest the integration of the patch into the official VDR tree before the next stable release. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] femon request; historic data
On Fri, 11 Nov 2011, Torgeir Veimo wrote: Am wondering if it would be hard to enhance the femon plugin to show a graph of signal quality and correction statistics? Basically, a histogram with STR, SNR, BER and UNC, so that one doesn't have to oogle the screen constantly to see how signal quality changes. Even better if it was possible to trigger such monitoring without the femon display showing. It should be more feasible to utilize the original command line femon tool and RRDtool instead of the plugin. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] vdr-1.7.21 DVB-T2 support
Hi, here's my attempt to provide a native DVB-T2 support for VDR. - added initial libsi support for the required T2 delivery system descriptor - updated bandwidth, modulation, transmission, guard settings to match DVB-T2 specs - added a new PLP id to channel parameters and tuning mechanism - requires DVB API 5.3 - implementation is analog to the current DVB-S/S2 extending the existing delivery system field - shortcomings: PLP id can be found also in DVB-T channel configuration (but doesn't affect anything) and the new channels.conf values could be a bit more intuitive It seems to work here in Finland with my limited access to local DVB-T2 muxes, but no guarantees. :) BR, -- rofa vdr-1.7.21-dvbt2-support.patch.gz Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.21
On Sun, 25 Sep 2011, semsem85 sami wrote: I have made a 2 min recording on one of sky italia channels. Here is the link: Hope this helps. Your sample doesn't have any DVB subtitles tracks, so I guess you really should be using the ttxtsubs plugin as VDR won't support nor record them by default: http://projects.vdr-developer.org/projects/plg-ttxtsubs BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.21
On Wed, 21 Sep 2011, semsem85 sami wrote: I tried this version of vdr with the aim of displaying subtitles on sky italia channels but there were no subtitles shown at all, while at the same time tvheadend shows the subtitles. Please tell me if I have to do something to help. If you have somewhere such a recording available, I could take a look at it and make sure my patch really fixes subtitling on those Sky Italia channels. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] dvb-s(2) NumProvidedSystems() vs reelchannelscan
On Sat, 21 May 2011, Klaus Schmidinger wrote: I'm thinking about giving cDevice a function that returns a bit masked value, identifying the delivery systems it provides. Probably using the fe_delivery_system_t constants from the LinuxDVB API. Could you take again a look at my frontend facilities patch and modify the current cDevice API a bit further at the same time? BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] OSD character set
On Sat, 5 Feb 2011, Sami Sundell wrote: However, there's a teensy issue with the OSD: it looks like its characters are in UTF-8, when the system is ISO-8859-1. The finnish translation file is nowadays in UTF-8 (as most of the Linux distributions), but gettext should handle the charset conversion automatically. Somehow this conversion seem to fail on your system. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe open hug OSD
On Tue, 1 Feb 2011, Niko Mikkilä wrote: Since SourceForge's CVS servers are still down, it may be a bit tricky to get the latest and greatest version. The GIT mirror is still up and always pretty up-to-date: http://projects.vdr-developer.org/git/?p=xineliboutput.git BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-sxfe open hug OSD
On Mon, 31 Jan 2011, Oliver Schinagl wrote: I'm still having trouble getting this all working. I used http://www.vdr-portal.de/board/thread.php?postid=818661 to get me through the setup, without avail. --opengl-all doesn't seem to be a valid option? Or I can't find anything about it. --hud works however. $ vdr-sxfe --help vdr-sxfe 1.0.90-cvs (build with xine-lib 1.1.90, using xine-lib 1.1.90) snip -D, --hud[=flag[,flag]] Head Up Display OSD mode using compositing flags: xshape Use XShape instead of compositing opengl Use OpenGL instead of compositing -O, --openglUse OpenGL for video and Head Up Display OSD snip -- vdr-sxfe --hud vdr-sxfe --hud=xshape vdr-sxfe --hud=opengl vdr-sxfe --hud=opengl --opengl would have been loads easier if vdr-sxfe would simply act as the most minimalistic window manager by itself and create the hud window itself. Patches are always welcome. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] naludump 0.0.1
On Sat, 22 Jan 2011, Udo Richter wrote: Thought of that too, for a longer perspective. However, what do you think where to add such a hook ideally? My original idea was to hook in cDevice::Action() as it would bring most flexible setup to blacklist/rewrite pids. However, I forgot the current section mechanism and pat/pmt parsing. Adding a hook to cDevice::Action would affect all streams, including transfer mode and streaming etc., but has no known relation between PID and stream type. Also, there may be several video streams in parallel here. And I wouldn't consider it good style to provide just filtered streams for all in any case. Wouldn't stripping NALU fill data help to reduce the required network bandwidth for streamdev, xineliboutput, and vnsi plugins? I do see many benefits using filtered streams everywhere. You could also transcode only certain video/audio pids as the device class know its' transponder/channel parameters. Adding a hook to cRecorder::Receive() would be nice, as (although not explicitly specified) the data is received as single TS packets, which would allow packet dropping easily. Also, the packets can easily be checked for the (one and only) video PID and video type. However, Receive() is supposed to return immediately, esp. since its called within a Lock() of the device. You could simply hook up into the ringbuffer methods used in cRecorder. A more flexible way would be to add yet another ring buffer between the receiving buffer and the frame detector, and do the hook between the buffers. But another buffer will be additional overhead... ..and you already thought about it. :) Anyway, it's up to the plugin how big the overhead will be and it wouldn't hurt when recording. It's up to the user how many recording filters she's going to chain... BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] naludump 0.0.1
On Sat, 22 Jan 2011, Timothy D. Lenz wrote: Has anyone here every used or seen an STB's rotor support? The one I have is a first gen Neusat SP-6000. Maybe those of you with the interest in doing it and programing skill to tackle it have a sat store near by where you can see one and get a look at the setup functions. OR find a cheap one on ebay. Ask in the forum at http://www.satelliteguys.us/ for which units are good examples or for recomendations of options/functions that are useful. Might even be able to get some screen shots for ref design. Combine the best of has been done. A lot of those guys have several STB's and have seen/tried many more. Well, this looks like hijacking a thread, but I'll give my 2 cents anyway. Howabout just polising the current GotoX patch and convince Klaus to merge it into upcoming developer versions. IMO, it should be simple enough for a core feature in both feature and setup wise. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Developer versions
On Wed, 12 Jan 2011, VDR User wrote: And you get VDR's full osd doing this? FYI, xineliboutput provides three different OSD implementations: xinelib, composite HUD, and opengl HUD. For example the composite HUD OSD is drawn directly onto transparent window located exactly over the (xine-lib powered) video window and therefore is completely independent from the actual video decoding library. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Request: E parameter in channels.conf for epg scan
On Mon, 6 Dec 2010, Mario Schulz wrote:
Am 05.12.2010 23:33, schrieb Klaus Schmidinger:
What would that be necessary for?
I'd like to prevent EIT scans on IPTV devices.
In its default behaviour VDR will add transponders and channels to the
channels.conf, as a result these will be searched and probably result in
a match and a timer entry, even for uninteresting or undecodable channels.
The following patch might expose the necessary API for plugins to create
white and/or blacklists for EIT scanning on certain devices/channels.
BR,
--
rofa
diff -Nru vdr-1.7.16-vanilla/device.c vdr-1.7.16-eitscan/device.c
--- vdr-1.7.16-vanilla/device.c 2010-09-19 19:42:08.0 +0300
+++ vdr-1.7.16-eitscan/device.c 2010-12-06 17:36:33.0 +0200
@@ -56,6 +56,11 @@
return true;
}
+bool cDeviceHook::DeviceProvidesEITScan(const cDevice *Device, const cChannel
*Channel) const
+{
+ return true;
+}
+
// --- cDevice ---
// The default priority for non-primary devices:
@@ -594,6 +599,17 @@
return true;
}
+bool cDevice::DeviceHooksProvidesEITScan(const cChannel *Channel) const
+{
+ cDeviceHook *Hook = deviceHooks.First();
+ while (Hook) {
+if (!Hook-DeviceProvidesEITScan(this, Channel))
+ return false;
+Hook = deviceHooks.Next(Hook);
+}
+ return true;
+}
+
bool cDevice::ProvidesTransponder(const cChannel *Channel) const
{
return false;
diff -Nru vdr-1.7.16-vanilla/device.h vdr-1.7.16-eitscan/device.h
--- vdr-1.7.16-vanilla/device.h 2010-09-19 19:42:08.0 +0300
+++ vdr-1.7.16-eitscan/device.h 2010-12-06 17:41:18.0 +0200
@@ -96,6 +96,8 @@
/// program ends.
virtual bool DeviceProvidesTransponder(const cDevice *Device, const cChannel
*Channel) const;
/// Returns true if the given Device can provide the given
Channel's transponder.
+ virtual bool DeviceProvidesEITScan(const cDevice *Device, const cChannel
*Channel) const;
+ /// Returns true if the given Device can scan EIT on the given
Channel's transponder.
};
/// The cDevice class is the base from which actual devices can be derived.
@@ -204,6 +206,8 @@
static cListcDeviceHook deviceHooks;
protected:
bool DeviceHooksProvidesTransponder(const cChannel *Channel) const;
+public:
+ bool DeviceHooksProvidesEITScan(const cChannel *Channel) const;
// SPU facilities
diff -Nru vdr-1.7.16-vanilla/eitscan.c vdr-1.7.16-eitscan/eitscan.c
--- vdr-1.7.16-vanilla/eitscan.c2010-09-19 19:42:08.0 +0300
+++ vdr-1.7.16-eitscan/eitscan.c2010-12-06 17:38:40.0 +0200
@@ -146,7 +146,7 @@
if (Device) {
for (cScanData *ScanData = scanList-First(); ScanData;
ScanData = scanList-Next(ScanData)) {
const cChannel *Channel = ScanData-GetChannel();
- if (Channel) {
+ if (Channel
Device-DeviceHooksProvidesEITScan(Channel)) {
if (!Channel-Ca() || Channel-Ca() ==
Device-DeviceNumber() + 1 || Channel-Ca() = CA_ENCRYPTED_MIN) {
if (Device-ProvidesTransponder(Channel)) {
if (!Device-Receiving()) {
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Minor *.po patch
On Mon, 6 Dec 2010, Ville Skyttä wrote: On Saturday 04 December 2010, Tobias Grimm wrote: The gettext version I use automatically adds a Language field to the headers of the po-Files. It would be nice to have this field there in the first place, so here's a small patch that adds it. The Language fields for the main dialect of a language should not have _COUNTRY (i.e. Language: de, not Language: de_DE etc). More info: http://www.gnu.org/software/gettext/manual/gettext.html#Header-Entry Fill in the language code of the language. This can be in ONE of three forms: ‘ll’, ‘ll_CC’, ‘ll...@variant’ Where is the country code forbidden exactly? The core VDR doesn't have same language for different areas, but i.e. the femon does: zh_CN and zh_TW. If I would use the plain zh for both of these, the zh_TW.po file would be interpreted as zh_CN and that really doesn't sound rigth. With VDR's current language files this doesn't make any difference, but I prefer Tobias' patch with your language team modifications a bit more future proof. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Minor *.po patch
On Tue, 7 Dec 2010, Ville Skyttä wrote: Don't stop reading there. I don't know about forbidden, but they do write that the value is something else, a bit below the above quoted part: I didn't! :) * In this PO file field, but not in locale names, ‘ll_CC’ combinations denoting a language's main dialect are abbreviated as ‘ll’. For example, ‘de’ is equivalent to ‘de_DE’ (German as spoken in Germany), and ‘pt’ to ‘pt_PT’ (Portuguese as spoken in Portugal) in this context. * In this PO file field, suffixes like ‘.encoding’ are not used. * In this PO file field, variant designators that are not relevant to message translation, such as �...@euro’, are not used. So, if your locale name is ‘de_DE.UTF-8’, the language specification in PO files is just ‘de’. So, de is a synonym for de_DE and both definitions are as correct as they can be according to my interpretation. But leaving out the country only applies to _the_ (there can be only one I gather) primary dialect of a language. So both zh_CN and zh_TW cannot be the primary dialect; dunno if there's such a thing for Chinese in the first place. If you look at my patch carefully, you'll see that for zh_CN.po the value of the Language field is zh_CN. And you could use here the plain zh as it defaults to zh_CH - according to my quick Google searchs. I did not invent any of these values myself - I just first fixed the Language- Team fields so that gettext itself understands them, and then ran the files through gettext, and copied/included in my patch what gettext itself had added. I think following what gettext's docs say/recommend and what it actually does itself is the best approach. In that case those plain language codes are enough. I was just thinking about new translation that might come in future using subdialects. Translators usually uses the existing ones as a starting point and might not remember to update these fields correctly. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Feature-Request: MarginStart in INFO file of recording
On Tue, 2 Nov 2010, VDR User wrote: Wouldn't this also require that you sync your system time to the dvb stream also? It would be nice if someone wrote a patch or plugin to cut out commercials. From what I've _heard_ mythtv has this features and it works quite well. There's already the Markad plugin, that's been developed quite actively: http://projects.vdr-developer.org/projects/plg-markad BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr cpu usage
On Wed, 20 Oct 2010, Theunis Potgieter wrote: I'm not trying to start a flame war or who is to blame but are there ways I can inspect to see which plugin is causing it, if is a plugin to blame. You could check those time consuming VDR thread(s) via the htop command and then look for the corresponding thread id(s) from your VDR/system log to check what they really are. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Thu, 14 Oct 2010, Vesa wrote: Next step is to add delay for subtitles. This is dirty trick, it is only for eHD users. Simply add some value to Delta (add second line): Code: Delta = LimitTo32Bit(sb-Pts()) - LimitTo32Bit(STC); Delta += 50; With that 5 you will get 5.56s delay. With that eHD now works correctly with recording play. Live shows subtitles will be too late with this, but it is minor issue. I mostly watch recordings :) Would it help to modify the plugin's GetSTC() method only when replaying? + if (Replaying()) +STC -= 50L; // or configurable: 900L * ReelSetup.STCDelayMs; BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Replay Problems with Extension HD
On Wed, 13 Oct 2010, Vesa wrote: Similar delay as on ttxsubtitles would be nice addition to VDR. Separate and additional delay for live and record play modes. Suitable range would be 0 - 10s. Well, IMO that delay code in the ttxtsubs plugin should be removed when PTS code has been merged into the repo. This would fix also other issue than non working output. Sometimes How about adding a STC offset setting in these non working output plugins with a little help of latest PCR value and the system clock? My opinion is that there is several reason to add DVB subtitle delay setting to VDR menu. To fix non working output devices and to fix temporally miss aligned subtitles. This feature is similar as Lipsync set on all modern AV devices. Audio should be in sync with video, but sometimes it is not. It is good to have lipsync on menu for fixing this temporal but totally annoying issue. I'm against these kind of dirty hacks in the official VDR code tree, but the current dvbsubtitles code in VDR could be refactored to be replaceable with a plugin. Afterwards the reel plugin could reimplement it with any hacks needed. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-webvideo 0.3.2
On Sat, 11 Sep 2010, Antti Ajanki wrote: On 09/11/2010 01:44 PM, Jouni Karvo wrote: May I suggest adding a VDRINCLUDEDIR variable, and -I option, and removing the vdr/ from the #include statements in the future versions. Thanks for the suggestion. I will add variable for the include dir as you proposed. I'd rather suggest to use the VDR standard to compose the Makefile: VDRDIR = ../../.. ... -include $(VDRDIR)/Make.global -include $(VDRDIR)/Make.config ... INCLUDES += -I$(VDRDIR)/include BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-iptv-plugin DVB subtitles problems
On Wed, 8 Sep 2010, Fake Name wrote: Here is the VLC recording: I downloaded this file, added it into channels.conf via FILE protocol (S=1|P=0|F=FILE|U=vlc.ts), set VDR to update pids and to show subtitles and finally setup Slovak as a preferred language. The subtitles were shown automatically and couldn't find any problems, but one. The stream has CA descriptor present and you'll have to patch the VDR with vdr-1.7.15-disable_ca_updates.patch in order to get rid of Channel not available messages. Test was made with the latest development version of the plugin, but there shouldn't be any significant modifications against the public release. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-iptv-plugin DVB subtitles problems
On Wed, 8 Sep 2010, Fake Name wrote: Stream 3 Type: Subtitle Original ID: 7302 Codec: DVB Subtitles (dvbs) Language: sloven??ina Description: DVB subtitles HBO;IPTV:110:S=0|P=0|F=UDP|U=239.1.1.151|A=5000:I:0:810=2:8...@4:7302:0:222:0:0:0 Somehow your VDR thinks that the pid 7302 is teletext and not DVB subtitle. DVBsubs pids aren't stored into channels.conf, but always detected dynamically. If I record the video with VDR and run dvbsnoop |grep 7302 (subtitles id) I get no results (dvbsnoop can't analyze live iptv streams). I also dumped the stream with mplayer and tried playing back the video, but there were no subtitles (record subtitles is checked in options). But because this is the first time I ran dvbsnoop and even after reading dvbsnoops man pages, I'm not sure if I did everything right. I'm also not very good with mplayer, so i ran with -alang, maybe I'm doing something wrong? Last time I checked the mplayer it didn't support DVBsubs, but I had to hack the support by myself (google: mplayer-dvbsubs-svn-20091207.patch.gz). You should really should provide us a small piece of original multicast stream recorded with emcast/vlc/... BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-iptv-plugin DVB subtitles problems
On Wed, 8 Sep 2010, Fake Name wrote: I manualy entered the teletext pid, because I started experimenting. Oh. I see. What suprises me, is that your plugin detects the subtitle pid Info/PIDs correctly (thank you for your work btw). It's not the plugin, but the VDR itself and therefore I don't have a slightest idea what might be wrong. Here is the VDR recording: Here is the VLC recording: Thanks. I'll take a look at them. Btw, we should switch to using private emails in order not to spam the mailing list with these boring debug messages. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] DIVX recordings? :)
On Sun, 5 Sep 2010, Teemu Suikki wrote: So basicly I would like to be able to compress vdr recording to divx, but still view it like normal VDR recording. It would be quite enough Why don't you just use H.264 TS instead of Divx? VDR already natively supports it... BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Understanding AC-3
On Fri, 3 Sep 2010, Rob Davis wrote: Do we need to check it's ATSC if type is 0x81? Does anything else use it and is it a problem if it does? The values 0x80-0xFF are so called User Private in the standard, so in theory you cannot assume them to be ATSC. But you could detect the ATSC streams from their registration descriptor (hopefully) and after that adapt dynamically to ATSC video and AC-3 pids. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Understanding AC-3
On Thu, 2 Sep 2010, Rob Davis wrote: How do you go about understanding AC-3 within a VDR context? (apart from reading up on it online - which now has my head spinning). The current ATSC AC-3 support requires the 'A' source type for channels and therefore VDR never use ATSC hacks for any pvrinput channel. A quick and dirty hack would be adding an additional check for the pvrinput source type into cChannel::IsAtsc(). BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] New ATSC Video Type 0x80?
On Thu, 2 Sep 2010, Rob Davis wrote: I will attempt to diagnose tomorrow, probably by adding another Case 0x80 under Case 2 in pat and remux but wanted to point this out for future reference as I know most of the development is done outside of the ATSC world.. If you'll take a look at the table 7.4 in ANSI/SCTE 57, you'll see that the stream type 0x80 is DigiCipher2 video and 0x81 is used for AC-3: http://www.scte.org/documents/pdf/standards/ANSISCTE572003DVS507.pdf IMO, the current channel-IsAtsc() check in pat.c should be replaced with a stream identification via the registration descriptor. Then it's back to working out why my pvr-hd ac-3 (h264 and ac3 @ 720p) don't work in vdr-xine and xbmc/vnsi.. (although do work in vdr-xineliboutput and xbmc/streamdev..) I guess XBMC/VNSI is using their own PMT parser, so you'll have to add these same hacks into them. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] recording teletext (like for subtitles...)
On Sun, 11 Jul 2010, Halim Sahin wrote: Just interested to know: Q: why do you want to record teletext stuff? What's an useful usecase for that? EBU/teletext subtitling is still actively used in plenty of DVB channels. Sure, one could convert these into textual DVB subtitles, but only a few video editors/players supports them. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] recording teletext (like for subtitles...)
On Sat, 10 Jul 2010, Juergen Lock wrote: page and the threads I linked, I also have made a hack to make vdr 1.7.15 timers include teletext in the ts recordings, maybe this is useful as a first start to properly implement that feature. I'll You might like to have a look at my tpid patch that implements subtitling page numbers and channels.conf support that are currently missing in your patch: http://www.saunalahti.fi/~rahrenbe/vdr/patches/vdr-1.7.15-tpid.patch.gz The tpid patch is nowadays superceded by a patchset done under ttxtsubs that was intended to be the basis of ttxtsubs implementation in core VDR (patches 0001-0005): http://projects.vdr-developer.org/repositories/browse/plg-ttxtsubs/patches/patch-set.1.7.15 BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Xine plugins and LATM AAC audio (was Re: vdr 1.7.15 eHD French HD DTV)
On Wed, 23 Jun 2010, Luis Fernandes wrote: and yes Femon 1.7.7 does not detect this audio codec, this one must be I've added a preliminary LATM parser to femon-1.7.8 that will be hopefully released tonight. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-femon-1.7.7 vdr-iptv-0.4.0 vdr-skinsoppalusikka-1.7.1 vdr-rssreader-1.7.0
On Fri, 12 Mar 2010, Klaus Schmidinger wrote: Not sure if this applies here, but there was a bug in VDR 1.7.13's channel editing in cDvbSourceParam. Well, there were bugs also in the plugin, but those should already be fixed in 0.4.1. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] streamdev-server and pvrinput: TS-mode streaming is not working
On Thu, 11 Mar 2010, L. Hanisch wrote: What am I missing? Looking at cReceiver::AddPid, a receiver is not able to set the PID 0 (which is the PAT-PID), but PAT packets should be processed through a filter, right? IIRC, you'll need to implement section filtering into your input plugin (implement virtual OpenFilter() and CloseFilter() methods and start/stop the actual handling by calling StartSectionHandler()/StopSectionHandler(). You can take a look at the IPTV plugin, how this can be handled in non-DVBAPI environment. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-femon-1.7.7 vdr-iptv-0.4.0 vdr-skinsoppalusikka-1.7.1 vdr-rssreader-1.7.0
On Sun, 7 Mar 2010, ? ?? wrote: What about iptv patches? No IsPlug() member in cChannel. IPTV doesn't need patches anymore. Where do you need this kind of method? May be need Channel-Source() cSource::st_Mask == 'I'24 This is already done in cIptvDevice::ProvidesSource(). BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-femon-1.7.7 vdr-iptv-0.4.0 vdr-skinsoppalusikka-1.7.1 vdr-rssreader-1.7.0
On Mon, 8 Mar 2010, ? ?? wrote: But I have another trouble. Any suggestions? I guess there's a bug somewhere in cIptvTransponderParameters::Parse() and ::ToString(), but my eyes cannot catch that one. :) BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-femon-1.7.7 vdr-iptv-0.4.0 vdr-skinsoppalusikka-1.7.1 vdr-rssreader-1.7.0
On Sat, 6 Mar 2010, Timothy D. Lenz wrote: Nothing below that. I have a dual ATSC and a single ATSC tuner card and I guess you're using the new ATSC patch and femon doesn't support it. Something else I notice now is the left/right arrows both advance through the tuners where before the left counted backwards. Thanks for the info. That's a confirmed bug. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-femon-1.7.7 vdr-iptv-0.4.0 vdr-skinsoppalusikka-1.7.1 vdr-rssreader-1.7.0
New releases of my plugins are now available for vdr-1.7.13: http://www.saunalahti.fi/~rahrenbe/vdr/femon/ 2010-03-05: Version 1.7.7 - Updated for vdr-1.7.13. - Added a setup option to downscale the OSD size. - Updated Estonian translation (Thanks to Arthur Konovalov). http://www.saunalahti.fi/~rahrenbe/vdr/iptv/ 2010-03-05: Version 0.4.0 - Updated for vdr-1.7.13. - Fixed argument corruption. http://www.saunalahti.fi/~rahrenbe/vdr/soppalusikka/ 2010-03-05: Version 1.7.1 - Updated for vdr-1.7.13. http://www.saunalahti.fi/~rahrenbe/vdr/rssreader/ 2010-03-05: Version 1.7.0 - Updated for vdr-1.7.13. - Added Estonian translation (Thanks to Arthur Konovalov). BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-femon-1.7.7 vdr-iptv-0.4.0 vdr-skinsoppalusikka-1.7.1 vdr-rssreader-1.7.0
On Fri, 5 Mar 2010, Timothy D. Lenz wrote: Not a big deal, but I notice that femon doesn't give as much infor about the tuner as before. It was listing the tuner chip, now that lower section is just blank. Works for me with my terrestrial cards. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
On Wed, 3 Mar 2010, Timothy D. Lenz wrote: If it's going to be limited to 1 letter, v does seem right for video, i for iptv would be good. I think ATSC uses ether c or t. Not sure. But if I understand what is happening here, might be a good idea to go to a 2 or 3 letter ID right now so things don't have to be patched latter. IPTV will be using 'I' - at least my initial implementation does. Anyway I cannot imagine a situation that there ever will be more input plugins than there are available visible characters (26 [A-Z] + 26 [a-z] + 10 [0-9] + ...). BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.13
On Thu, 4 Mar 2010, Timothy D. Lenz wrote: May not need 30+ symbols, but to keep to symbols that somewhat match what they are for would call for reuse of some letters. Well, even I do prefer I - IPTV, but I don't see no problems using X - IPTV. The description of source params explains perfectly the source in both cases - no matter what the type character is. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] remote femon (was OT: Applications for the living room)
On Mon, 1 Mar 2010, Theunis Potgieter wrote: On 28 February 2010 16:59, Frank Schmirler v...@schmirler.de wrote: On Wed, 24 Feb 2010 10:50:06 +0200, Theunis Potgieter wrote The only annoying bug that I found was, that if I ran femon on the client, it would stop the server's current replay of a recording. I guess that is the fault of vdr-femon? Currently femon provides signal information for VDRs ActualDevice only, i.e. the device which receives the DVB stream for output on the local primary device. So if a client wants to get signal information for its current channel, it has to tune the same channel on the server. And tuning a channel via SVDRP stops replaying recordings. So not vdr-femon to blame then. My apologies. Well, vdr-femon could disable zapping while a server is replaying. Patches are always welcome. :) BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Hauppauge PVR-HD and pvrinput plugin (was: Re: Hauppauge PVR-HD and IPTV plugin)
On Tue, 9 Feb 2010, L. Hanisch wrote:
I received your sample and it looks like a valid TS with PAT, PMT and PCR,
so the plugin has nothing else to do as to pass it through to the vdr
(hopefully).
In the meanwhile, one could also try out the IPTV plugin without any
ffmpeg hassle by using a script that tunes the device and then simply:
cat /dev/video0 | nc -u -p ${PORT} 127.0.0.1
BR,
--
rofa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Hauppauge PVR-HD and IPTV plugin
On Mon, 8 Feb 2010, Rob Davis wrote: [h264 @ 0x808eb00]no picture [mpegts @ 0x85f2a80]dts pcr, TS is invalid Then it just freezes... Does the ffmpeg command work on the commandline? Might be related to the ffmpeg revision... Anyway, you could give a try for the FILE input protocol as it should be quite perfect for your TS source. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Hauppauge PVR-HD and IPTV plugin
On Mon, 8 Feb 2010, Rob Davis wrote: I tried to put /dev/video0 as a file but couldn't get anything out of VDR... Saying that I'm pretty sure I removed the h264 VDR patch since coming to the US. I'm running VDR 1.6 instead of 1.7 as I know what I'm doing better with it in Gentoo.. Well, it seems that /dev/video0 won't output TS stream, so the FILE protocol unfortunately isn't suitable. Would there be a way to watch a file and call a script? That way I can execute an external channel changer depending on parameter and then dump the output to a fifo.. Not at this momenta and the pvrinput plugin seems much nicer approch for this. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] A few things about DVB subtitles
On Wed, 3 Feb 2010, Petri Helin wrote: Yes, I am using xineliboutput and also VDR as the subtitles decoder. Ok. I've just added a patch into xineliboutput's cvs and it should fix this (preparing for next vdr release) - at least it did in my quick tests. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.12 folders.conf
On Sat, 6 Feb 2010, Klaus Schmidinger wrote: On 06.02.2010 12:27, Halim Sahin wrote: Hi, Just my opinion about the problem: The fat filesystem has many limitations and I vote for dropping special support for it in VDR because if someone wants to use a windows system, he/she can use ntfs which works fine in current distributions (ntfs-3g). Just my 2 Cents. I would do that in a heartbeat - but I guess that would cause a huge flame war... ;-) Without VFAT-option I encountered huge problems with my Samba shares and FAT32 formatted USB sticks, so I'm against dropping this feature. :) Anyway back to real problem, my original idea was to add an extra / cMenuFolderItem object into NestedItemList in cMenuFolder constructors, or you could always easily assign a new key short cut to reset the folder (i.e. k0). BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.12 folders.conf
On Fri, 5 Feb 2010, Klaus Schmidinger wrote: How about '.'? (w/o the single quotes). That would result in /video/./name, which is the same as /video/name. That was my initial idea too, but due to the VFAT conversion a '#2E' sub-directory will be made instead of the root directory. I'm using this same cMenuFolder class in my rename recordings patch, but the same problem should exist in the vanilla timers edit menu too. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] A few things about DVB subtitles
On Wed, 3 Feb 2010, Petri Helin wrote: Thanks. But with a quick test with VDR 1.7.11 I could not get the subtitles to stay visible. They still disappear after their lifetime has been spent. Well, it worked with my FF card. :) If you're using xineliboutput, make sure you're also using VDR as subtitles decoder. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] vdr-1.7.12 folders.conf
Hi, the current folder setting feature for timers doesn't have easy way to reset the selected folder back to the root one - or I just missed it. I'd really like to see this little addition in the next vdr release. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.12 folders.conf
On Wed, 3 Feb 2010, Klaus Schmidinger wrote: Well, you can always position to the file name, pres Right and then Yellow to delete the folder part of the name. Yes, but IMO that's not an easy way. :) I was thinking about a special root directory entry for folders.conf. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] A few things about DVB subtitles
On Wed, 13 Jan 2010, Petri Helin wrote: 1. Pausing. At the monet the subtitles will disappear like in a live view - meaning that VDR seems to adhere the life time assignened to a subtitle image though the replay has been paused, causing the subtitles to disappear. The attached patch should handle this - in a way. Ofcourse, the elapsed time of shown subtitle should be stored when paused and re-set after the replaying has started again. But it would complicate the patch and I don't see any real-life benefits for it. BR, -- rofa vdr-1.7.11-pausedsubtitles.patch.gz Description: Binary data ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Location of subtitles
On Fri, 22 Jan 2010, Magnus H wrote: I run xineliboutput from CVS and get my subtitles un-scaled in the upper-left 720x576 area on my 1366x768 display. This means really small text just below the middle of the screen aligned to the left, on both 720x576 and 1920x1080 transmissions. Sorry about that. Didn't test the unscaled OSD implementation and ofcourse there was couple of bugs, but those should be fixed now in CVS. The subtitles should now be center aligned on the bottom of the screen. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput vdpau crop
On Fri, 15 Jan 2010, Seppo Ingalsuo wrote: Actually I'd prefer the unscaled 576i/p subtitles size on 1080p scaled video but on the center bottom position. The current scaled subtitles are too big and coarse at 46. Has anyone hacked the DVB subtitles like that? The current CVS version should now do this when using unscaled HD OSD resolution. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Location of subtitles
On Fri, 22 Jan 2010, JJussi wrote: I managed go around this problem, by changing directly in setup.conf, offset value to 500. The CVS version of xineliboutput should already handle the correct location of subtitles without any additional tricks as it's always rendering subtitles into a 720x576 OSD layer. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new support
On Thu, 21 Jan 2010, Rob Davis wrote: Can you get the channel scan done from something else and post a mplayer or vlc command for each channel. Once you've done that I'll knock you up a quick iptv script.. You really should consider write a new plugin (i.e. based on the iptv plugin) for it instead of hacking the iptv plugin. This would enable integrated channel scanner, dynamically assigned tuners, more robust zapping, ... BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] new support
On Thu, 21 Jan 2010, Nicolas Huillard wrote: For those who don't spare some time digging on the website: * this is an Ethernet device: antenna in (single, dual), ethernet out * no storage inside the box * they provide an LGPL library libhdhomerun: include hdhomerun.h and/or hdhomerun_device.h to use the top level API I'd make another 'pseudo' DVB input device plugin for this based on the current IPTV plugin. A quick look at the API reveals that you could dynamically add necessary number of provided tuners as done in IPTV plugin. You could also implement a channel scan functionality as done in IPTV plugin. I quess its' UDP/RTP transport is already compatible with the one implemented in IPTV plugin. The only requirement from core VDR would be the pluginparam patch (or similar) functionality. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xineliboutput vdpau crop
On Sun, 3 Jan 2010, Mika Laitio wrote:
If I watch vdr-sxfe just from a small window, the subtitle and text are
positioned correctly with a good looking font size to bottom of the screen.
But if I watch finish yle 1 channel which uses dvb subtitles from
fullscreen vdr-sxfe, the subtitle font is small and text is positioned about
to middle of the screen. (Left position is correct)
Have you tried to change the subtitles decoder from VDR to xine?
Anyway, the problem is that the resolution and position information of
subtitles is 720x576. If your output resolution differs from that, the
subtitles are misplaced. The attached patch might help you as it should
scale the subtitles osd always to 720x576 (found it on my hd and it
comes with perävalotakuu :) when using VDR's subtitles decoders.
BR,
--
rofaIndex: osd.c
===
RCS file: /cvsroot/xineliboutput/vdr-xineliboutput/osd.c,v
retrieving revision 1.38
diff -u -r1.38 osd.c
--- osd.c 19 Aug 2009 17:15:37 - 1.38
+++ osd.c 1 Dec 2009 11:58:38 -
@@ -20,6 +20,10 @@
#include osd.h
+#ifndef OSD_LEVEL_TTXTSUBS
+#define OSD_LEVEL_TTXTSUBS 20 // from ttxtsubs plugin
+#endif
+
//#define LIMIT_OSD_REFRESH_RATE
#define LOGOSD(x...)
@@ -366,11 +370,16 @@
#if VDRVERSNUM = 10708
- double Aspect;
- intW, H;
- m_Device-GetOsdSize(W, H, Aspect);
- m_ExtentWidth = W;
- m_ExtentHeight = H;
+ if(xc.osd_scaling ((m_Layer==OSD_LEVEL_SUBTITLES) || (m_Layer==OSD_LEVEL_TTXTSUBS))) {
+m_ExtentWidth = 720;
+m_ExtentHeight = 576;
+ } else {
+double Aspect;
+intW, H;
+m_Device-GetOsdSize(W, H, Aspect);
+m_ExtentWidth = W;
+m_ExtentHeight = H;
+ }
#else
@@ -439,9 +448,16 @@
if(!m_IsVisible)
return;
- int SendDone = 0;
+ int SendDone = 0, XOffset = 0, YOffset = 0;
+ if(!xc.osd_scaling ((m_Layer==OSD_LEVEL_SUBTITLES) || (m_Layer==OSD_LEVEL_TTXTSUBS))) {
+double Aspect;
+intW, H;
+m_Device-GetOsdSize(W, H, Aspect);
+XOffset = (H - 576) 0 ? (H - 576) : 0;
+YOffset = ((W - 720) / 2) ? ((W - 720) / 2) : 0;
+ }
for (int i = 0; (Bitmap = GetBitmap(i)) != NULL; i++) {
-int x1 = 0, y1 = 0, x2 = Bitmap-Width()-1, y2 = Bitmap-Height()-1;
+int x1 = XOffset, y1 = YOffset, x2 = x1+Bitmap-Width()-1, y2 = y1+Bitmap-Height()-1;
if (m_Refresh || Bitmap-Dirty(x1, y1, x2, y2)) {
/* XXX what if only palette has been changed ? */
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dynamic PIDs
On Tue, 24 Nov 2009, Jouni Karvo wrote: Tried this, but it seems it loses the subtitling PIDs. Is there a way to get both - subtitling and non-breaking TV viewing? Oh, I forgot that the spids aren't present in channels.conf, so you need to patch the vdr in a way or another. I guess the quick'n'dirty fix would be adding support for spids into channels.conf... BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Dynamic PIDs
On Mon, 23 Nov 2009, Jouni Karvo wrote: is there somewhere a patch that would remove the break when the broadcaster uses dynamic pids (such as YLE). Now, when a programme starts at YLE, they change the Audio PID number, leading to VDR re-tuning or something, that leads to a 1-2s break in the show. There is no change in frequency, so I don't see any reason why there is such a break. As a quick fix just disable the pid updates (Channel update: no/names only). Yle is always using the same pid numbers although they're switching them on and off, so you can easily fix these numbers in your channel.conf. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7 and no subtitles with old PES recordings
On Tue, 6 Oct 2009, j...@mbnet.fi wrote:
I'm contemplating updating my trusty 1.6.0 to the latest
development version, but I can't seem to get DVB subtitles
from old recordings to work.
Subtitles are shown corretly both when viewing live tv and
when viewing new recordings, but when viewing old PES
recordings VDR just says that no subtitles are available.
I'm using vanilla VDR and the xineliboutput plugin.
Zimiq did all the hard work to pinpoint the faulty method:
http://www.linuxtv.fi/viewtopic.php?p=24394#24394
At least this patch did help on my few old recordings:
--- dvbsubtitle.c.orig 2009-11-17 18:29:16.0 +0200
+++ dvbsubtitle.c 2009-11-17 18:30:44.0 +0200
@@ -699,7 +699,7 @@
}
if (Length PayloadOffset + SubstreamHeaderLength) {
-int64_t pts = PesGetPts(Data);
+int64_t pts = PesHasPts(Data) ? PesGetPts(Data) : 0;
if (pts)
dbgconverter(Converter PTS: %lld\n, pts);
const uchar *data = Data + PayloadOffset + SubstreamHeaderLength; //
skip substream header
BR,
--
rofa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] simple recordings patch
On Tue, 20 Oct 2009, martinez wrote: The patch is against 1.3.37. But it should work with older and younger versions too. This patch is also included in the Liemikuutio all-in-one patch, that's available even for the latest development VDR. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR 1.7 and no subtitles with old PES recordings
On Tue, 6 Oct 2009, j...@mbnet.fi wrote: I searched through the archives and the only mention of a similar problem I could find is the one below, but unfortunately no solution. I debugged this a while ago and the problem is that the difference of PTS and STC is way off in old PES recordings and therefore VDR discards all subtitles. I wasn't keen enough to fix it, so if somebody has plenty of free time.. :) BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-iptv-0.3.1
Hi, a new version of the IPTV plugin is now available: 2009-10-01: Version 0.3.1 - Updated patches. - Added optional patches to disable EIT scanning. - Fixed handling of HTTP protocol headers. - Modified sectionfilters to use socket pair instead of filesystem fifos. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-femon-1.7.5
Hi, a new version of the femon plugin for vdr-1.7.x series is now available. The H.264 parser is still missing some bits, so patches are welcome. http://www.saunalahti.fi/~rahrenbe/vdr/femon/ 2009-10-01: Version 1.7.5 - Changed H.264 parser to show display aspect ratio. - Removed error logging from unimplemented ioctl functions. - Removed bitstream parsing from Receive() method. - Added Chinese translation (Thanks to NanFeng). BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] IPTV: Problems with Base port number
On Fri, 18 Sep 2009, Rob Davis wrote: I am trying to get BBC Radio streams to work. However, I can't work out how to get the IPTV plugin to chage the base port.. The base port is a global setting that can be changed in plugin's setup: iptv.ExtProtocolBasePort=4321 However, if you create more than one IPTV device, the device's base port is the one defined in setup plus device's enumeration: Device 0: 4321 Device 1: 4322 These should be documented (somehow) in plugin's README. mplayer and ffmpeg are bother created. (as per the example script) with a different fifo each, but VDR is sending the same PORT to all streams, so if I change channel I get the two streams mixed together. If you're having only one IPTV device, the script should be killed (and mplayer/ffmpeg as well) before the new one is executed with new channel specific parameters when zapping. There were some protocol specific bugs in the channel switching, so you should try the latest public 0.3.0 release, if not already done. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] IPTV: Problems with Base port number
On Fri, 18 Sep 2009, Rob Davis wrote: How do I create more than one IPTV device? I assumed that it was automatic? I am using 0.3.0. -d num, --devices=number number of devices to be created -P 'iptv -d 2' When vdr switches off the channel how is the channel / stream closed? A SIGINT is signaled to the external script. If the script isn't terminated in 2 seconds, a SIGKILL is signaled. This is a blocking mechanism, so you shouldn't be able to run two scripts at the same time within a device. I'm suspecting, that your mplayer/ffmpeg processes won't get killed although the external script does. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] IPTV: Problems with Base port number
On Fri, 18 Sep 2009, Rob Davis wrote: It doesn't seem too. I now have the script killing ffmpeg when it closes, but if I try two channels at the same time of different frequencies they come with the same port. You could compile the plugin with IPTV_DEBUG=1, zap through the channels, document the actions and finally send me the logs, channels.conf, and the used script as a private email and I'll take a look at them. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] femon plugin doesn't work ERROR (femonosd.c, 504): Function not implemented
On Tue, 15 Sep 2009, Dieter Bloms wrote: Sep 15 08:37:36 video vdr: [17541] ERROR: cOsd::SetAreas returned 6 Your OSD is running out of memory. The only cure is to shrink your current OSD size. Sep 15 08:37:36 video vdr: [18526] ERROR (femonosd.c,504): Function not implemented Your DVB driver doesn't provide the FE_READ_UNCORRECTED_BLOCKS ioctl - it shouldn't be fatal. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] femon plugin doesn't work ERROR (femonosd.c, 504): Function not implemented
On Tue, 15 Sep 2009, Martin Dauskardt wrote: Rolf, you know that this happens with the vdr default OSD size? Well, you should get the memory upgrade for your FF card. :) Femon adapts its' window size now only with VDR's OSD width/height settings, but also with the size of small font. Decreasing the size of the small font reduces also the memory requirements. You could also change the used theme theme to Duotone that makes use of 2bpp instead of 4bpp windows and therefore uses less memory. Sep 8 20:26:27 ubuntuvdr vdr: [3668] ERROR: cFemonOsd::cFemonOsd() OSD height (461) smaller than required (480). This indicates that the (small) font size clashes with the OSD size settings. Why is it not possible to show all femon OSD content with the vdr default OSD size? I don't remember that I had to change the OSD size with earlier vdr/plugin versions. There shouldn't be any problems with the Duotone theme, but on the other hand I find it too ugly for a default one. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-femon-1.7.4
On Sun, 30 Aug 2009, Goga777 wrote: which IRC channel do you mean ? xine-vdpau ? Well, you can find me on both IRCnet and Freenode - you'll just have to quess the nick. :) Anyway, there's a new hot fix release available: http://www.saunalahti.fi/~rahrenbe/vdr/femon/ 2009-09-04: Version 1.7.4 - Fixed H.264 bitstream parser. - Added a mutex to receiver class. - Added 1080/720/576/480 format symbols into status window. There're still a few missing/buggy features in H.264 parser: interlaced/progressive detection doesn't work and therefore the code path is disabled. Also the frame rate is currently really the field rate of the video stream. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-femon-1.7.3
Hi, a new femon plugin release is now available for latest development vdr versions: http://www.saunalahti.fi/~rahrenbe/vdr/femon/ 2009-08-29: Version 1.7.3 - Removed OSD offset and height options. - Added PES assembler. - Added bitstream parsers for all codecs. There has been a major rewrite since the previous release, so I might have broken the AAC/AC3/H.264 bitstream parsers as I don't have such streams available and couldn't find any beta testers either. Please, report any regressions by email/IRC. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] femon - stream information
On Fri, 24 Jul 2009, Torgeir Veimo wrote: Would it be hard to enhance the femon plugin to show some stream information, eg progressive v interlaced and stream resolution, eg 480p, 576p, 1080i etc? It already does some stream parsing as is, to determine mpeg2 vs h.264? Nope - most of the code is already there: only a simple ts2pes buffering class is missing as all required data doesn't fit into a one TS packet with H.264. I don't have access to any H.264 channels, so I won't implement any further. Also I'm waiting Klaus' decision about enchanhing the cDevice API as certain information are quite useful i.e. for skins. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] femon - stream information
On Fri, 24 Jul 2009, Lucian Muresan wrote: this might be slightly OT, but I thought it would be worth pointing out if talking about future releases of the femon plugin. Would you like to take a look at my quick hack which makes the femon OSD width adaptive and consistent to the global OSD width (for HD displays): The similar feature is already implemented in the git repository, so it will be available in the next public release. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-iptv-0.3.0
On Tue, 16 Jun 2009, Matthias Haas wrote:
thank you for this release. I just have one problem. It seems as if the
new version tends to start a vlc process (i.e. I have internet radios
configured) some time after my vdr is started. It seems to be connected
to the epg scan or some other process that is triggered some time after
I start the vdr process. I did not have the problem with my previous
version of the plugin 0.2.6.
VDR does EIT scanning to transponders in background and this starts up
your VLC processes as you suspected. However, the downgrading to earlier
version is not a proper solution as it brings up some other problems.
The 0.3.0 should be compliant with VDR's API definitions, but I you
don't likethe background EIT scanning, you can always disable it via
setup menu or with the following patch (if you want to disable it only
for plugin sources):
--- vdr-1.7.8-vanilla/eitscan.c 2009-06-15 17:31:45.0 +0300
+++ vdr-1.7.8-disable_eitscan/eitscan.c 2009-06-17 10:52:17.0
+0300
@@ -146,7 +146,7 @@
if (Device) {
for (cScanData *ScanData = scanList-First(); ScanData;
ScanData = scanList-Next(ScanData)) {
const cChannel *Channel = ScanData-GetChannel();
- if (Channel) {
+ if (Channel !Channel-IsPlug()) {
if (!Channel-Ca() || Channel-Ca() ==
Device-DeviceNumber() + 1 || Channel-Ca() = CA_ENCRYPTED_MIN) {
if (Device-ProvidesTransponder(Channel)) {
if (!Device-Receiving()) {
BR,
--
rofa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 16 colour OSD for vdr
On Fri, 12 Jun 2009, Theunis Potgieter wrote: it seems my old graphix card nvidia 440 MX, doesn't support more than 16 colours, when it should do OSD and xxmc :( is there a skin or theme that I can use taht would work good in a 16 colour environment? currently I'm using skinsoppalusikka. The only colour I can see is the blue bar at the top, the rest are black. You should disable antialising as it makes soppalusikka to default 8bpp. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-iptv-0.3.0
Hi, a new version of IPTV plugin is now available and contains an important bug fix that enables correct channel switches between different protocols. http://www.saunalahti.fi/~rahrenbe/vdr/iptv/ 2009-06-01: Version 0.3.0 - Added iptvstream-notrap.sh script. - Fixed setting parameters when protocol changes (Thanks to Peter Holik for reporting this one). - Updated example scripts to use ffmpeg's direct UDP output and added a new image.sh script (Thanks to Peter Holik). BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] xinelibout sxfe freeze
On Wed, 20 May 2009, Malcolm Caldwell wrote: Is sxfe freezing a known issue? Any fix? Yes, I tracked down the bug and informed the author months ago. Last time I communicated to him, he had a (possible) fix running on his development setup, but I haven't checked lately, if it had been commited to CVS. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Can I disable pause live tv altogher?
On Fri, 8 May 2009, Pasi Juppo wrote: It seriously would not hurt VDR if there were Help pages available via OSD. Yes, there are man-pages but my guess is that very very few end users will actually go to terminal to check man-pages if they have some problems with VDR how to do something. They just don't bother. And this is request for Klaus because he's the author of the VDR thus should keep the help pages of VDR up-to-date. And preferably all plugin developers would do the same. Some plugins (all of mine for example) do have manual/help. You'll need just to press Info button to access them on plugin's active setup entry. This would be quite beneficial for core VDR too as many options are quite hard to understand at the first glance and a separate Keymap menu item would be a nice addition into the setup menu for averate users. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Re: VDR-1.7.7 Video aspect ratios (was: [ANNOUNCE] VDR developer version 1.7.7)
On Sun, 3 May 2009, Tomas Berglund wrote:
Do you mean aspect ratio 2.21:1 ?
+const char *VideoAspectString[] = { 4:3,
+16:9,
+2.21:9
+ };
Besides of that typo, there're plenty of video aspect ratios missing:
1:1, 12:11, 10:11, 16:11, 40:33, 24:11, 20:11, 32:11, 80:33, 18:11,
15:11, 64:33, 160:99, 3:2, 2:1.
Anyway, I'm not very fond of this new interface addition. After a little
playing with xineliboutput plugin in the past, the OSD scaling to video
size is a total mess and hence the HUD mode was developed, where the
OSD resolution is the same as the output resolution and the video is
scaled to that resolution. I'd strongly suggest to implement
cDevice::GetOSDSize(), so the output plugins can correctly set their
OSD resolution with minimal scaling artefacts.
Of course, you could misuse the current GetVideoSize always to result an
output (OSD) resolution, but that would break i.e. all skin plugins that
will certaily make use of this new method.
BR,
--
rofa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.7.7 Video aspect ratios
On Mon, 4 May 2009, Nicolas Huillard wrote:
Rolf Ahrenberg a écrit :
On Sun, 3 May 2009, Tomas Berglund wrote:
Do you mean aspect ratio 2.21:1 ?
+const char *VideoAspectString[] = { 4:3,
+16:9,
+2.21:9
+ };
Besides of that typo, there're plenty of video aspect ratios missing:
1:1, 12:11, 10:11, 16:11, 40:33, 24:11, 20:11, 32:11, 80:33, 18:11,
15:11, 64:33, 160:99, 3:2, 2:1.
16:10 is also a common device aspect ratio these days ;-)
Well, those values (taken from H.264 specs) were for the video aspect
ratio and not the output aspect ratio. IIRC, the H.264 contains also so
called extended aspect ratio, that could contain almost anything.
BR,
--
rofa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR-1.7.7 Video aspect ratios
On Mon, 4 May 2009, Falk Spitzberg wrote: The OSD should adopt to the size of the video material. If that is scaled to some non TV screen size, the OSD is scaled by the same factor. I still disagree. If you scale down your OSD to video resolution (i.e. 544x576) and afterwards scale up the both video and OSD to output resolution (i.e. 1280x720), the OSD really looks crap due to scaling artefacts. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [iptv] [input_vdr] No data in 8 seconds, queuing no signal image
On Sat, 2 May 2009, Paul Menzel wrote: I followed [3] and the README.Debian of the vdr-plugin-iptv package from [4]. I came up with the following. I don't know what Debian suggests users to do, but the EXT protocol is always a secondary solution and the UDP (or HTTP) protocol is the primary users should always try first. iptv (0.2.5) - Experience the IPTV You should upgrade to 0.2.6 in order to get rid of crashes in section filters. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Record with 1.7.4 or 1.7.5 and iptv
On Mon, 27 Apr 2009, Senufo wrote: I found the error. With IPTV you must define the type of stream in channels.conf In my channels.conf I wrote No, yo don't have to. The IPTV plugin has section filters implemented (if don't disable/blacklist them in setup options!). They seem to work in your setup too, but, please, correct me if your channel 39 isn't France 2. A snip from your first post.: France 2;IPTV:2:IPTV|S0P0|UDP|232.0.1.1|8200:P:0:1201=2:1301:0:0:1:0:0:0 changing pids of channel 39 from 0+0=2:0:0:0 to 1210+1210=27:1310=fra:0:0 If the channel 39 really is the France 2, so question still remain, why the VDR's video type detection fails on TF1 as the mplayer do it rigth. You could provide a small video sample recording the multicast stream with i.e. emcast. http://www.gizmolabs.org/~dhelder/junglemonkey/emcast/ BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-skinsoppalusikka-1.6.4 vdr-rssreader-1.6.4
Hi, new releases of Skinsoppalusikka and RSSReader plugins are now available. These releases fix a crash bug in SVDRP help detected only on some setups: http://www.saunalahti.fi/~rahrenbe/vdr/soppalusikka/ 2009-04-14: Version 1.6.4 - Updated Italian translation (Thanks to Diego Pierotto). - Cleaned up compilation warnings. - Fixed a crash bug in the SVDRP help. http://www.saunalahti.fi/~rahrenbe/vdr/rssreader/ 2009-04-14: Version 1.6.4 - Fixed RSS parsing. - Updated Italian translation (Thanks to Diego Pierotto). - Fixed a crash bug in the SVDRP help. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] vdr-skinsoppalusikka-1.6.4 vdr-rssreader-1.6.4
On Tue, 14 Apr 2009, Lauri Tischler wrote: One might humbly assume that these for VDR 1.6.x only ? Almost correct: vdr-1.6.x or later. There haven't been any major API changes for these plugins, so no need to branch dedicated 1.7.x series yet. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] ERROR (thread.c,225): Keine Berechtigung
On Wed, 8 Apr 2009, Gerald Dachs wrote: On every start of the vdr I get this error message: Apr 2 00:33:36 vdr vdr: [2462] ERROR (thread.c,225): Keine Berechtigung It comes from cThread::SetPriority and seems to be harmless, but annoying. Is the attached patch the right cure? I've solved this by tweaking the capabilities. google: vdr-1.6.0-cap_sys_nice.patch BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-rssreader-1.6.3
Hi, a new RSSReader plugin release is now available: http://www.saunalahti.fi/~rahrenbe/vdr/rssreader/ 2009-04-05: Version 1.6.3 - Cleaned up compilation warnings. - Fixed a crash bug when pressing OK in an empty menu. - Fixed RSS parsing. - Added correct character set conversion tables for ISO-8859-2, ISO-8859-15 and CP1250. - Updated example/rssreader.conf. - Added a new LOAD SVDRP command. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-iptv-0.2.6
Hi, a new IPTV plugin release is now available: http://www.saunalahti.fi/~rahrenbe/vdr/iptv/ 2009-03-22: Version 0.2.6 - Added a note about recommended frequencies into README. - Fixed a locking bug with section filters. - Fixed some lint warnings. I strongly encourage every IPTV user to upgrade the plugin, as the locking bug in older versions caused crashing during zapping on certain VDR setups. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-iptv-0.2.5
On Mon, 16 Mar 2009, ua0lnj wrote: 1. Have: use section filtering - yes, disable filters - 0. Have a iptv channel in channel.conf, but absent and not streaming now. Switch channels: work channnel - absent channel - work channel. And vdr hangs, almost always Could you attach the gdb to the vdr process and check where does it hang exactly? If set use section filtering - no, all works. If set use section filtering - yes, disable filters - 1, PAT, all works too. So, it's somehow related to cPatFilter. As the pid updating works nicely on my setup, this might be related to video stream data itself... 2. pat.c use Channels.GetByServiceID. Channels.GetByServiceID use ISTRANSPONDER(). #define ISTRANSPONDER(f1, f2) (abs((f1) - (f2)) 4) We must use frequencies differ 4 in iptv channels. TV1;IPTV:1:IPTV|S1P0|UDP|127.0.0.1|1234:P:0:512:650:2321:0:1:0:0:0 - third parametr. Never use: TV1;IPTV:1:IPTV|S1P0.. need use (example): TV1;IPTV:10:IPTV|S1P0.. Otherwise ISTRANSPONDER() not works correct... Did I understood you correctly: if you're setting the channel frequency to 10 instead of 1, your VDR won't hang anymore with section filtering (including PAT) enabled? Why would (abs(1-1)4) be different than abs(10-10)4? Anyway, you could trace the values given to ISTRANSPONDER() macro and see if that gives any hint about the problem. PS. You can also send bug reports and questions directly to me without polluting the mailing list. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr 1.7.4 HD-Recording not working
On Wed, 11 Mar 2009, Oliver Bardenheier wrote: Mar 11 17:43:12 Coruscant vdr: [15544] cVideoRepacker: operating in H.264 mode Mar 11 17:43:12 Coruscant vdr: [15544] cAudioRepacker(0xC0): skipped 216 bytes to sync on next audio frame Are you really using vdr-1.7.4? IIRC, both the video and audio repackers were removed due to switching TS recording format in vdr-1.7.3 BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [ANNOUNCE] vdr-iptv-0.2.5
Hi, a new IPTV plugin release is now available: http://www.saunalahti.fi/~rahrenbe/vdr/iptv/ 2009-03-08: Version 0.2.5 - Optimized TS packet data flow. - Refactored section filter class. - Cleaned up example scripts. - Fixed pid scanner to set the existing video stream type (Thanks to ua0lnj for reporting this one). - Added optional patches to disable CA updates. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.4 and iptv plugin
On Sat, 7 Mar 2009, ua0lnj wrote: My suggestions 1. My iptv provider streams many channels with identical pids, and vdr not very love such channels :-) If in sidscanner.c chandge cChannel *IptvChannel = Channels.GetByChannelID(channel.GetChannelID()); to cChannel *IptvChannel = Channels.GetByServiceID(Source(), Transponder(), assoc.getServiceId()); vdr iptv plugin can work with duplicate pids channel more correct. This might have some unwanted negative effects on certain situations. I'll need to think about it. 2. My iptv provider retranslate sat channels in iptv, after decrypting, but not remove CA Descriptor from stream. And when I enable use section filtering and not disable PAT my iptv channels geting CA descriptor and vdr can't display this channels. Be a fine have option for disable use CA Descriptor in iptv, or vdr can be ignore it. You'll need to patch VDR for this: comment the Channel-SetCaIds() line at the end of pat.c. This affects all channels, so you might want to still keep the CA updates for normal channels: if (!Channel-IsPlugin()) Channel-SetCaIds(). Remember to clear out the CA field in channels.conf after the change. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.4 and iptv plugin
On Sat, 7 Mar 2009, ua0lnj wrote: If I change in pidscanner.c I can see all channels. Thanks. That is a bug in the current pid scanner and will be corrected in the next version. What is a stream type = 47 ??! IIRC, it's a reserved area. Who must change stream type to actual, vdr or iptv plugin? VDR. However, if the IPTV stream doesn't contain correct PAT sections, the pid scanner should be enabled in the IPTV plugin to do a basic video and audio pid detection. I can send a ts dump, how long and what mail? I guess there's no need for that anymore. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.4 and iptv plugin
On Thu, 5 Mar 2009, ua0lnj wrote: Sometimes when change channel I can see normal iptv aprox. 3 sec, but after still picture again... vdr: [5981] changing pids of channel 259 from 501+501=2:502:0:0 to 501+501=0:502:0:0 vdr: [5852] retuning due to modification of channel 259 VDR's PAT/PMT scanner detects changes in pid information usually after a few seconds and the channel it retuned as your log states. If you look at the change, you'll see that VDR changes the video stream type from MPEG2 (2) to an invalid/reserved (0) value. Software decoders might rely on that that information and therefore cannot display the video. As a quick hack, you should disable PAT tables in IPTV's section filter (or disable channel updates in VDR) and manually edit the channel entry to use a correct video stream type (501+501=2). Now, the real question is why the video stream type is marked as zero in your streams: a bug in vdr, a bug in iptv plugin, or some kind of attempt from your provider to allow only their proprietary hardware? If it's the latter one, you could try simply to make VDR detect stream type 0 as a MPEG2 (0x02) or H264 (0x1B) stream in pat.c, although I cannot see how you could end up with non-zero video pid with zeroed video type in current VDR code base. Are you using any other VDR patches than the pluginparam? You could always provide us a stream dump for further analyzing: $ emcast 127.0.0.1:1234 dump.ts BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr-1.7.4 and iptv plugin
On Wed, 4 Mar 2009, ua0lnj wrote: IPTV-0.2.4 plugin not works for me, I can see steel picture only, from time to time. But on info screen of plugin I can see stream's data. If you're using an external application (like vlc) to transcode the video stream and you see only still pictures, you'll most likely need a faster CPU. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Vote your VDR patches
On Mon, 2 Mar 2009, Pertti Kosunen wrote: jori.hamalai...@teliasonera.com wrote: I think one important patch is missing for DVB subtitles users, which makes old vdr-subtitles -plugin's recorded subtitles visible also for new subtitles by Klaus. Is this included in liemikuutio? Yes. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] cStatus::OsdClear
On Sun, 22 Feb 2009, Jörg Wendel wrote:
found :), the cause is a patch which is includes in the extension patch, due
to this the result of cMenuMain::Update is always true since
Setup.MainMenuTitle is not configured to 0 ('default'):
#ifdef USE_LIEMIKUUTIO
I will contact the patch developer.
...and these patch hunks don't belong to Liemikuutio patch although
the define suggests so, so you'll have to blame the extension patch
author.
BR,
--
rofa
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Wishlist: Genre
On Sun, 22 Feb 2009, Lauri Tischler wrote: Adding decoding of content descriptor would be nice. It would allow recording of all soaps or football matches or whatever without close watching of EPG. patching of VDRADMIND might be needed. google: vdr-1.6.0-parentalrating-content.diff.gz BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Section Filter Read Abstraction
On Mon, 26 Jan 2009, Deti Fliegl wrote: when using cDevice based classes that have no access to kernel based section filters it makes sense to have an abstract 'ReadFilter' function. The patch attached adds such a method to the cDevice class and changes cSectionHandler code to use the new method. The IPTV plugin manages this by creating pipes for section filters, so you can make software-only devices also with the current API. Anyway, this API modification would be a nice addition. BR, -- rofa ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
