Re: [vdr] [ANNOUNCE] VDR developer version 2.1.3
Whatever gets implemented, please make sure the user can disable it. I can't remember why but VDR's internal channel population has never worked right for NA so it's better to be kept as optional when it comes to auto-removing channels, parsing si tables, etc. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 2.1.3
Am 06.01.2014 09:59, schrieb Reinhard Nissl: > But this still seems error prone -- looks like a more complex solution > is needed which keeps track of how often a transponder has been seen > dead over a certain period of time before declaring these channels > OBSOLETE (and later delete them automatically). > > I don't know if it is worth to extend the file format of channels.conf > for that tracking, but at least in memory VDR could keep track of that, > starting from scratch whenever VDR is restarted. I have a little patch running doing exactly this, the patch just tracks the last-seen timestamp within the running session, or the state 'not seen in this session'. Load/save is not implemented, everything gets reset at program start. Its a whopping 8-lines patch. This is accompanied by a plugin that extends the last-seen time by syncing with the patch data from time to time, and keep the time together with the channel ID persistently stored in a separate file. If a channel wasn't announced for a month, it gets marked as gone. However, this doesn't differentiate why a channel wasn't seen, for example because the machine was off for a longer time, or the required receiver isn't connected. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] diseqc.conf for Spaun and quad-LNBs
Hi all,
I recently moved to Australia and now an looking to make my vdr work.
I have two quad LNBs (single local oscillator frequency) attached to a
Spaun 9x7 multi-switch.
The spaun is set to "Quad mode".
For the S156E position ("satellite A") I can tune to both H+V and run a
channel scan.
For the satellite "B" (S160E) I cannot tune anything - neither with vdr
nor with dvbscan.
On S156E I have a Foxtel (Sky-equivalent) box attached and it tunes
nicely, too. So maybe the Foxtel box did send some commands to the LNB
which made it work, whereas on S160E this did not happen (yet) ?
Can anybody please help with the correct diseqC.conf ?
My attempt (see below) to modify the one from
http://www.vdr-portal.de/index.php?page=Thread&postid=927921
did not work so far.
Thanks
Martin
# from this thread
# http://www.vdr-portal.de/index.php?page=Thread&postid=927921
# multiswitch + 2x Quad LNBs
##Multischalter Eingang A
#S13.0E 11700 V 9750 t v W15 [E0 10 38 F0] W15 A W15 t
#S13.0E 9 V 10600 t v W15 [E0 10 38 F1] W15 A W15 T
#S13.0E 11700 H 9750 t V W15 [E0 10 38 F2] W15 A W15 t
#S13.0E 9 H 10600 t V W15 [E0 10 38 F3] W15 A W15 T
##Multischalter Eingang B
#S19.2E 11700 V 9750 t v W15 [E0 10 38 F4] W15 B W15 t
#S19.2E 9 V 10600 t v W15 [E0 10 38 F5] W15 B W15 T
#S19.2E 11700 H 9750 t V W15 [E0 10 38 F6] W15 B W15 t
#S19.2E 9 H 10600 t V W15 [E0 10 38 F7] W15 B W15 T
#
#Multischalter Eingang A
S156E 9 V 10700 t v W15 [E0 10 38 F0] W15 A W15 t
#S156E 9 V 10700 t v W15 [E0 10 38 F1] W15 A W15 T
S156E 9 H 10700 t V W15 [E0 10 38 F2] W15 A W15 t
#S156E 9 H 10700 t V W15 [E0 10 38 F3] W15 A W15 T
#Multischalter Eingang B
#S160E 11700 V 9750 t v W15 [E0 10 38 F4] W15 B W15 t
S160E 9 V 10700 t v W15 [E0 10 38 F5] W15 B W15 T
#S160E 11700 H 9750 t V W15 [E0 10 38 F6] W15 B W15 t
S160E 9 H 10700 t V W15 [E0 10 38 F7] W15 B W15 T
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Update satellites in default sources.conf
On 06.01.2014 13:39, Antti Hartikainen wrote: On Mon, Jan 06, 2014 at 12:24:38PM +0100, Klaus Schmidinger wrote: On 06.01.2014 11:28, Antti Hartikainen wrote: Hi. I thought it would be time to finally update outdated sources.conf. Patch is against sources.conf delivered with VDR 2.1.3. Some things came up, and I would like to hear some opinions about them. There was/is entries like: S28.2E for Astra 2 satellites and S28.5E for Eutelsat satellite at almost same orbital position Both satellites are supposed to be watched with one dish and LNB, but still they have their own entries in sources.conf. Similar example is "S1W Thor 5/6 & Intelsat 10-02". Thor satellites are positioned 0.2 degrees apart from Intelsat. So should these satellites nearby eachother to be combined as one, or should every one to be separated as its own position? If these are officially two separate positions, they should be contained as such in sources.conf. I have encountered the same problem while implementing the DiSEqC configuration dialog. My approach will be to make cDiseqcs::Get() search for a suitable DiSEqC entry with a certain tolerance. A value of +/-0.3 degrees would cover the cases you mentioned. Or should it be even +/-0.5? This is why I wanted to join them together, so if such change will be made, separate close to eachother positions don't really matter. I think 0.5 degrees might be too much apart (depends of configuration.. dish size specially) and rare condition, and making VDR to steer dish "in between" two would make too much complicity, right? This "tolerance" would mainly apply to setups that have a fixed dish pointing to a position at which there are two satellites close together. In my upcoming DiSEqC configuration dialog it will be only possible to specify *one* sat position per LNB, so the tolerance will allow receiving both positions in such cases. Whether the dish is actually directed to either one of the satellites, or "in between", is up to the user, depending on which position his preferred. If you have a motor dish it will always be positioned exactly to the requested angle, so there's no need to go "in between". And that's also a reason why sources.conf should contain separate values in such cases. Thanks for the revised patch (v3). Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [PATCH] Update satellites in default sources.conf
Oops, S16E is still wrong in v2, please check this v3 instead. --- sources.conf.orig 2013-05-23 13:10:23.0 +0300 +++ sources.conf2014-01-06 14:43:07.354491730 +0200 @@ -19,57 +19,59 @@ # Europe -S3E Eutelsat 3A & Rascom 1R -S4E Eurobird 4A -S4.8E Astra 4A -S7E Eutelsat W3A -S9E Eurobird 9A -S10EEutelsat W2A -S13EHotbird 6/8/9 -S16EEutelsat W2M & Eurobird 16A -S19.2E Astra 1H/1KR/1L/1M/2C -S21.6E Eutelsat W6 -S23.5E Astra 3A/3B -S25.5E Eurobird 2 +S3E Eutelsat 3A/3D & Rascom 1R +S4E Eutelsat 4B +S4.8E Astra 4A & SES 5 +S7E Eutelsat 7A +S9E Eutelsat 9A/Ka-Sat 9A +S10EEutelsat 10A +S13EEutelsat Hot Bird 13B/13C/13D +S16EEutelsat 16A/16B +S17EAmos 5 +S19.2E Astra 1KR/1L/1M/2C +S21.6E Eutelsat 21B +S23.5E Astra 3B +S25.5E Eutelsat 25B S26EBadr 4/5/6 -S28.2E Astra 2A/2B/2D -S28.5E Eurobird 1 +S28.2E Astra 1N/2A/2F +S28.5E Eutelsat 28A S30.5E Arabsat 5A S31.5E Astra 1G -S33EEurobird 3 & Intelsat New Dawn -S36EEutelsat W4/W7 -S38EPaksat 1 +S33EEutelsat 33A & Intelsat 28 +S36EEutelsat 36A/36B +S38EPaksat 1R S39EHellas Sat 2 -S40EExpress AM1 S42ETurksat 2A/3A S45EIntelsat 12 +S46EAzerspace-1 +S47.5E Intelsat 10 S49EYamal 202 +S52.5E Yahsat 1A S53EExpress AM22 -S55EInsat 3E -S56EBonum 1 +S56EDirecTV 1R S57ENSS 12 S60EIntelsat 904 S62EIntelsat 902 S64EIntelsat 906 S66EIntelsat 17 S68.5E Intelsat 7/10 -S70.5E Eutelsat W5 -S72EIntelsat 709 +S70.5E Eutelsat 70B +S72EIntelsat 22 # Asia S74EInsat 3C/4CR S75EABS 1A -S76.5E Apstar 2R -S78.5E Thaicom 5 -S80EExpress AM2/MD1 -S83EInsat 2E/4A -S85.2E Intelsat 15 -S87.5E Chinasat 5A -S88EST 1/2 -S90EYamal 201 +S76.5E Apstar 7 +S78.5E Thaicom 5/6A +S80EExpress AM2 +S83EInsat 4A +S85.2E Intelsat 15 & Horizons 2 +S87.5E ChinaSat 12 +S88EST 2 +S90EYamal 201/300K S91.5E Measat 3/3A -S92.2E Chinasat 9 +S92.2E ChinaSat 9 S93.5E Insat 3A/4B S95ENSS 6 S96.5E Express AM33 @@ -77,21 +79,22 @@ S103E Express A2 S105.5E Asiasat 3S S108.2E Telkom 1 & NSS 11 & SES 7 -S110E N-Sat 110 & BSAT 2C/3A -S110.5E Chinasat 10 +S110E N-Sat 110 & BSAT 3A/3C +S110.5E ChinaSat 10 S113E Palapa D & Koreasat 5 -S116E Koreasat 6 +S115.5E ChinaSat 6B +S116E ABS 7 & Koreasat 6 S118E Telkom 2 +S119.5E Thaicom 4 S122.2E Asiasat 4 -S124E JCSAT 4A -S125E Chinasat 6A -S128E JCSAT RA -S132E Vinasat 1 & JCSAT5A +S124E JCSAT 4B +S125E ChinaSat 6A +S128E JCSAT 3A +S132E Vinasat 1/2 & JCSAT 5A S134E Apstar 6 S138E Telstar 18 S140E Express AM3 S144E Superbird C2 -S146E ABS 5 S150E JCSAT 1B S152E Optus D2 S154E JCSAT 2A @@ -99,73 +102,73 @@ S160E Optus D1 S162E Superbird B2 S164E Optus B3 -S166E Intelsat 8 -S169E Intelsat 5 -S172E GE 23 -S180E Intelsat 701 +S166E Intelsat 19 +S169E Intelsat 8 +S172E Eutelsat 172A +S180E Intelsat 18 S177W NSS 9 # Atlantic S1W Thor 5/6 & Intelsat 10-02 S4W Amos 2/3 -S5W Atlantic Bird 3 -S7W Nilesat 101/102/201 & Atlantic Bird 4A -S8W Telecom 2D & Atlantic Bird 2 +S5W Eutelsat 5 West A +S7W Nilesat 101/201 & Eutelsat 7 West A +S8W Eutelsat 8 West A/C S11WExpress AM44 -S12.5W Atlantic Bird 1 +S12.5W Eutelsat 12 West A S14WExpress A4 S15WTelstar 12 S18WIntelsat 901 -S20WNSS 5 -S22WNSS 7 +S20WNSS 7 +S22WSES 4 S24.5W Intelsat 905 S27.5W Intelsat 907 -S30WHispasat 1C/1D/1E +S30WHispasat 1D/1E S31.5W Intelsat 25 S34.5W Intelsat 903 S37.5W NSS 10 & Telstar 11N -S40.5W NSS 806 +S40.5W SES 6 S43WIntelsat 11 S45WIntelsat 14 S50WIntelsat 1R -S53WIntelsat 707 +S53WIntelsat 23 S55.5W Intelsat 805 -S58WIntelsat 9/16 -S61WAmazonas 1/2 +S58WIntelsat 21 +S61WAmazonas 2/3 # America -S61.5W Echostar 12/15 +S61.5W Echostar 16 S63WTelstar 14R S65WStar One C1 +S67WAMC 4 S70WStar One C2 S72WAMC 6 -S72.5W DirecTV 1R & Nimiq 5 -S74WHorizons 2 -S77WEchostar 1/8 -S79WAMC 2/5 +S72.7W Nimiq 5 +S75WStar One C3 +S77WQuetzSat 1 S82WNimiq 4 S83WAMC 9 S84WBrasilsat B4 S85WAMC 16 S85.1W XM 3 -S87WAMC 3 +S87WSES 2 S89WGalaxy 28 -S91WGalaxy 17 & Nimiq 1 -S93WGalaxy 25 +S91WGalaxy 17 & Nimiq 6 +S93.1W Galaxy 25 S95WGalaxy 3C S97WGalaxy 19 -S99WGalaxy 16 -S99.2W Spaceway 2 & DirecTV 11 +S99.2W Galaxy 16 S101W DirecTV 4S/8 & SES 1 S103W AMC 1 S105W AMC 15/18 -S107.3W Anik F1/F1R +S107.3W Anik F1R/G1 S110W DirecTV 5 & Echostar 10/11 S111.1W Anik F2 S113W SatMex 6 -S116.8W SatMex 5 +S114.9W SatMex 5 +S116.8W SatMex 8 S118.8W Anik F3 S119W Echostar 14 & DirecTV 7S S121W Echostar 9/Galaxy 23 @@ -174,7 +177,7 @@ S127W Galaxy 13/Horizons 1 S129W Ciel 2 S131W AMC 11 -S133W Galaxy 13/15 +S133W
Re: [vdr] [PATCH] Update satellites in default sources.conf
On Mon, Jan 06, 2014 at 12:24:38PM +0100, Klaus Schmidinger wrote: > On 06.01.2014 11:28, Antti Hartikainen wrote: > > Hi. > > > > I thought it would be time to finally update outdated sources.conf. Patch > > is against sources.conf delivered with VDR 2.1.3. > > > > Some things came up, and I would like to hear some opinions about them. > > > > There was/is entries like: > > > > S28.2E for Astra 2 satellites and > > S28.5E for Eutelsat satellite at almost same orbital position > > > > Both satellites are supposed to be watched with one dish and LNB, but still > > they have their own entries in sources.conf. > > > > Similar example is "S1W Thor 5/6 & Intelsat 10-02". Thor satellites are > > positioned 0.2 degrees apart from Intelsat. > > > > So should these satellites nearby eachother to be combined as one, or > > should every one to be separated as its own position? > > If these are officially two separate positions, they should be contained as > such > in sources.conf. > I have encountered the same problem while implementing the DiSEqC > configuration > dialog. My approach will be to make cDiseqcs::Get() search for a suitable > DiSEqC entry with a certain tolerance. A value of +/-0.3 degrees would cover > the cases you mentioned. Or should it be even +/-0.5? This is why I wanted to join them together, so if such change will be made, separate close to eachother positions don't really matter. I think 0.5 degrees might be too much apart (depends of configuration.. dish size specially) and rare condition, and making VDR to steer dish "in between" two would make too much complicity, right? > > In this patch I have combined 28.2E and 28.5E positions as one 28.2E > > position, as atleast I have set them both up as one single position. > > Sorry, I don't think this is a good idea. > Please make them separate again if you want your patch to be adopted. Thanks for the feedback. I wasn't aware if this is intentional or just by mistake. I changed it back to two separate positions in revised patch. > > I also wanted to change S1W to S0.8W, as it's more true, but I can imagine > > it would cause a lot of trouble for people who are using the default > > sources.conf file as their sources.conf, so for now I left it as is. It > > doesn't really matter, but improves signal strength for people using > > USALS. :) > > The satellite position that is broadcast in the > SatelliteDeliverySystemDescriptor's > OrbitalPosition/EastWestFlag on that satellite actually says 1.0W, so I'd say > that's > what should be in sources.conf. I agree. I haven't examined any of such data that satellites may broadcast. Ofcourse I would prefer to keep official values for them. I made some slight changes to some postions like 3E -> 3.1E, but I have changed them back to original in revised patch. I didn't check what they broadcast, as I don't have knowhow to read such broadcast information from stream. There was some completely new positions in Asia and America region, so I have no possiblity to check any official positions for them anyway, as I reside in Europe and have no possibility to receive them. So v2 patch does not change any positions, only changes satellite names and adds new and removes old, no longer used satellite positions. Also in v2 changed "Hotbird" to "Eutelsat Hot Bird", as it is now called as such. --- sources.conf.orig 2013-05-23 13:10:23.0 +0300 +++ sources.conf2014-01-06 14:35:50.089495627 +0200 @@ -19,57 +19,59 @@ # Europe -S3E Eutelsat 3A & Rascom 1R -S4E Eurobird 4A -S4.8E Astra 4A -S7E Eutelsat W3A -S9E Eurobird 9A -S10EEutelsat W2A -S13EHotbird 6/8/9 -S16EEutelsat W2M & Eurobird 16A -S19.2E Astra 1H/1KR/1L/1M/2C -S21.6E Eutelsat W6 -S23.5E Astra 3A/3B -S25.5E Eurobird 2 +S3E Eutelsat 3A/3D & Rascom 1R +S4E Eutelsat 4B +S4.8E Astra 4A & SES 5 +S7E Eutelsat 7A +S9E Eutelsat 9A/Ka-Sat 9A +S10EEutelsat 10A +S13EEutelsat Hot Bird 13B/13C/13D +S16EEurobird 16A/16B +S17EAmos 5 +S19.2E Astra 1KR/1L/1M/2C +S21.6E Eutelsat 21B +S23.5E Astra 3B +S25.5E Eutelsat 25B S26EBadr 4/5/6 -S28.2E Astra 2A/2B/2D -S28.5E Eurobird 1 +S28.2E Astra 1N/2A/2F +S28.5E Eutelsat 28A S30.5E Arabsat 5A S31.5E Astra 1G -S33EEurobird 3 & Intelsat New Dawn -S36EEutelsat W4/W7 -S38EPaksat 1 +S33EEutelsat 33A & Intelsat 28 +S36EEutelsat 36A/36B +S38EPaksat 1R S39EHellas Sat 2 -S40EExpress AM1 S42ETurksat 2A/3A S45EIntelsat 12 +S46EAzerspace-1 +S47.5E Intelsat 10 S49EYamal 202 +S52.5E Yahsat 1A S53EExpress AM22 -S55EInsat 3E -S56EBonum 1 +S56EDirecTV 1R S57ENSS 12 S60EIntelsat 904 S62EIntelsat 902 S64EIntelsat 906 S66EIntelsat 17 S68.5E Intelsat 7/10 -S70.5E Eutelsat W5 -S72EIntelsat 709 +S70.5E Eutelsat 70B +S72EIntelsat 22 # Asia S74EInsat 3C/4CR S75EABS 1A -S76.5E Apstar 2R -S78.5E Thaicom 5 -S
Re: [vdr] [PATCH] Update satellites in default sources.conf
On 06.01.2014 11:28, Antti Hartikainen wrote: Hi. I thought it would be time to finally update outdated sources.conf. Patch is against sources.conf delivered with VDR 2.1.3. Some things came up, and I would like to hear some opinions about them. There was/is entries like: S28.2E for Astra 2 satellites and S28.5E for Eutelsat satellite at almost same orbital position Both satellites are supposed to be watched with one dish and LNB, but still they have their own entries in sources.conf. Similar example is "S1W Thor 5/6 & Intelsat 10-02". Thor satellites are positioned 0.2 degrees apart from Intelsat. So should these satellites nearby eachother to be combined as one, or should every one to be separated as its own position? If these are officially two separate positions, they should be contained as such in sources.conf. I have encountered the same problem while implementing the DiSEqC configuration dialog. My approach will be to make cDiseqcs::Get() search for a suitable DiSEqC entry with a certain tolerance. A value of +/-0.3 degrees would cover the cases you mentioned. Or should it be even +/-0.5? In this patch I have combined 28.2E and 28.5E positions as one 28.2E position, as atleast I have set them both up as one single position. Sorry, I don't think this is a good idea. Please make them separate again if you want your patch to be adopted. I also wanted to change S1W to S0.8W, as it's more true, but I can imagine it would cause a lot of trouble for people who are using the default sources.conf file as their sources.conf, so for now I left it as is. It doesn't really matter, but improves signal strength for people using USALS. :) The satellite position that is broadcast in the SatelliteDeliverySystemDescriptor's OrbitalPosition/EastWestFlag on that satellite actually says 1.0W, so I'd say that's what should be in sources.conf. Besides, if you change this, you would also have to change it in your diseqc.conf and in all entries in channels.conf that reference that position. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 2.1.3
On 06.01.2014 09:59, Reinhard Nissl wrote: Hi, Am 05.01.2014 12:42, schrieb Klaus Schmidinger: The changes since version 2.1.2: - Channels that are no longer contained in the current SDT of a transponder are now marked with the keyword OBSOLETE in their name and provider fields. That way you can identify obsolete channels when you switch to them, and you can get the complete overview of all obsolete channels by sorting the Channels list by provider (by pressing the 0 key twice). Automatic deletion of obsolete channels may follow later. What about channels on transponders which no longer get a lock while tuning, like S13.0E, 10930 H? The current way of detecting obsolete channels can only work if the transponder can still be received and a complete SDT is parsed. After that it is absolutely clear that any channel still in VDRs list, but not in the SDT, is obsolete. Shouldn't those channels be declared OBSOLTE too, when a SDT hasn't been received? Maybe this should only be done if the device doesn't have a lock either, to avoid false positives. There could be various reasons why a device might not have a lock, like a broken cable, bad weather, snow on the dish, or maybe the uplink for that particular transponder is temporarily interrupted. But this still seems error prone -- looks like a more complex solution is needed which keeps track of how often a transponder has been seen dead over a certain period of time before declaring these channels OBSOLETE (and later delete them automatically). I don't know if it is worth to extend the file format of channels.conf for that tracking, I do know: it is *not* ;-). The channels.conf file shall contain only information that is broadcast in the SI data. It's bad enough we have the infamous RID in there... but at least in memory VDR could keep track of that, starting from scratch whenever VDR is restarted. Maybe detecting "dead transponders" could work by checking whether any other transponder on the same source (and band (high/low, hor/ver) in case of DVB-S) can actually be received. If one transponder can't be received, but others on the same source/band can, then chances are the transponder is dead (unless the problem is with the uplink). However, I'm afraid this requires quite a bit more work than the simple detection of channels that are no longer in the SDT... Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] [PATCH] Update satellites in default sources.conf
Hi. I thought it would be time to finally update outdated sources.conf. Patch is against sources.conf delivered with VDR 2.1.3. Some things came up, and I would like to hear some opinions about them. There was/is entries like: S28.2E for Astra 2 satellites and S28.5E for Eutelsat satellite at almost same orbital position Both satellites are supposed to be watched with one dish and LNB, but still they have their own entries in sources.conf. Similar example is "S1W Thor 5/6 & Intelsat 10-02". Thor satellites are positioned 0.2 degrees apart from Intelsat. So should these satellites nearby eachother to be combined as one, or should every one to be separated as its own position? In this patch I have combined 28.2E and 28.5E positions as one 28.2E position, as atleast I have set them both up as one single position. I also wanted to change S1W to S0.8W, as it's more true, but I can imagine it would cause a lot of trouble for people who are using the default sources.conf file as their sources.conf, so for now I left it as is. It doesn't really matter, but improves signal strength for people using USALS. :) --- sources.conf.orig 2013-05-23 13:10:23.0 +0300 +++ sources.conf2014-01-06 12:06:20.790499108 +0200 @@ -19,57 +19,58 @@ # Europe -S3E Eutelsat 3A & Rascom 1R -S4E Eurobird 4A -S4.8E Astra 4A -S7E Eutelsat W3A -S9E Eurobird 9A -S10EEutelsat W2A -S13EHotbird 6/8/9 -S16EEutelsat W2M & Eurobird 16A -S19.2E Astra 1H/1KR/1L/1M/2C -S21.6E Eutelsat W6 -S23.5E Astra 3A/3B -S25.5E Eurobird 2 +S3.1E Eutelsat 3A/3D & Rascom 1R +S4E Eutelsat 4B +S4.8E Astra 4A & SES 5 +S7E Eutelsat 7A +S9E Eutelsat 9A/Ka-Sat 9A +S10EEutelsat 10A +S13EHotbird 13B/13C/13D +S16EEurobird 16A/16B +S17EAmos 5 +S19.2E Astra 1KR/1L/1M/2C +S21.6E Eutelsat 21B +S23.5E Astra 3B +S25.5E Eutelsat 25B S26EBadr 4/5/6 -S28.2E Astra 2A/2B/2D -S28.5E Eurobird 1 +S28.2E Astra 1N/2A/2F & Eutelsat 28A S30.5E Arabsat 5A S31.5E Astra 1G -S33EEurobird 3 & Intelsat New Dawn -S36EEutelsat W4/W7 -S38EPaksat 1 +S33EEutelsat 33A & Intelsat 28 +S36EEutelsat 36A/36B +S38EPaksat 1R S39EHellas Sat 2 -S40EExpress AM1 S42ETurksat 2A/3A S45EIntelsat 12 +S46EAzerspace-1 +S47.5E Intelsat 10 S49EYamal 202 +S52.5E Yahsat 1A S53EExpress AM22 -S55EInsat 3E -S56EBonum 1 +S56EDirecTV 1R S57ENSS 12 S60EIntelsat 904 S62EIntelsat 902 S64EIntelsat 906 S66EIntelsat 17 S68.5E Intelsat 7/10 -S70.5E Eutelsat W5 -S72EIntelsat 709 +S70.5E Eutelsat 70B +S72EIntelsat 22 # Asia S74EInsat 3C/4CR S75EABS 1A -S76.5E Apstar 2R -S78.5E Thaicom 5 -S80EExpress AM2/MD1 -S83EInsat 2E/4A -S85.2E Intelsat 15 -S87.5E Chinasat 5A -S88EST 1/2 -S90EYamal 201 +S76.5E Apstar 7 +S78.5E Thaicom 5/6A +S80EExpress AM2 +S83EInsat 4A +S85.2E Intelsat 15 & Horizons 2 +S87.5E ChinaSat 12 +S88EST 2 +S90EYamal 201/300K S91.5E Measat 3/3A -S92.2E Chinasat 9 +S92.2E ChinaSat 9 S93.5E Insat 3A/4B S95ENSS 6 S96.5E Express AM33 @@ -77,21 +78,22 @@ S103E Express A2 S105.5E Asiasat 3S S108.2E Telkom 1 & NSS 11 & SES 7 -S110E N-Sat 110 & BSAT 2C/3A -S110.5E Chinasat 10 +S110E N-Sat 110 & BSAT 3A/3C +S110.5E ChinaSat 10 S113E Palapa D & Koreasat 5 -S116E Koreasat 6 +S115.5E ChinaSat 6B +S116E ABS 7 & Koreasat 6 S118E Telkom 2 +S119.5E Thaicom 4 S122.2E Asiasat 4 -S124E JCSAT 4A -S125E Chinasat 6A -S128E JCSAT RA -S132E Vinasat 1 & JCSAT5A +S124E JCSAT 4B +S125E ChinaSat 6A +S128E JCSAT 3A +S132E Vinasat 1/2 & JCSAT 5A S134E Apstar 6 S138E Telstar 18 S140E Express AM3 S144E Superbird C2 -S146E ABS 5 S150E JCSAT 1B S152E Optus D2 S154E JCSAT 2A @@ -99,73 +101,73 @@ S160E Optus D1 S162E Superbird B2 S164E Optus B3 -S166E Intelsat 8 -S169E Intelsat 5 -S172E GE 23 -S180E Intelsat 701 +S166E Intelsat 19 +S169E Intelsat 8 +S172E Eutelsat 172A +S180E Intelsat 18 S177W NSS 9 # Atlantic S1W Thor 5/6 & Intelsat 10-02 S4W Amos 2/3 -S5W Atlantic Bird 3 -S7W Nilesat 101/102/201 & Atlantic Bird 4A -S8W Telecom 2D & Atlantic Bird 2 +S5W Eutelsat 5 West A +S7W Nilesat 101/201 & Eutelsat 7 West A +S8W Eutelsat 8 West A/C S11WExpress AM44 -S12.5W Atlantic Bird 1 +S12.5W Eutelsat 12 West A S14WExpress A4 S15WTelstar 12 S18WIntelsat 901 -S20WNSS 5 -S22WNSS 7 +S20WNSS 7 +S22WSES 4 S24.5W Intelsat 905 S27.5W Intelsat 907 -S30WHispasat 1C/1D/1E +S30WHispasat 1D/1E S31.5W Intelsat 25 S34.5W Intelsat 903 S37.5W NSS 10 & Telstar 11N -S40.5W NSS 806 +S40.5W SES 6 S43WIntelsat 11 S45WIntelsat 14 S50WIntelsat 1R -S53WIntelsat 707 +S53WIntelsat 23 S55.5W Intelsat 805 -S58WIntelsat 9/16 -S61WAmazonas 1/2 +S58WIntelsat 21 +S61WAmazonas 2/3 # Ame
Re: [vdr] [ANNOUNCE] VDR developer version 2.1.3
Hi, Am 05.01.2014 12:42, schrieb Klaus Schmidinger: The changes since version 2.1.2: - Channels that are no longer contained in the current SDT of a transponder are now marked with the keyword OBSOLETE in their name and provider fields. That way you can identify obsolete channels when you switch to them, and you can get the complete overview of all obsolete channels by sorting the Channels list by provider (by pressing the 0 key twice). Automatic deletion of obsolete channels may follow later. What about channels on transponders which no longer get a lock while tuning, like S13.0E, 10930 H? Shouldn't those channels be declared OBSOLTE too, when a SDT hasn't been received? Maybe this should only be done if the device doesn't have a lock either, to avoid false positives. But this still seems error prone -- looks like a more complex solution is needed which keeps track of how often a transponder has been seen dead over a certain period of time before declaring these channels OBSOLETE (and later delete them automatically). I don't know if it is worth to extend the file format of channels.conf for that tracking, but at least in memory VDR could keep track of that, starting from scratch whenever VDR is restarted. Bye. -- Dipl.-Inform. (FH) Reinhard Nissl mailto:rni...@gmx.de ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
