81 replies to this topic

[VU+NL]

Natuurlijk is zo'n "user" hack wel in te bouwen. Maar ik voel daar niets voor, zolang ik geen echt vat op de onderliggende problematiek heb. Ik denk liever een weekje langer na, om dan met een robuuste oplossing te komen.

Daar heb ik uiteraard niets op tegen. Het is natuurlijk geen probleem dat koste wat kost vandaag moet zijn opgelost: een doordachte oplossing heeft uiteraard de voorkeur.

Ik wil eerst zoeken naar een oplossing waarbij Enigma2 zelf uitpluist of een zender te ontvangen is.
Als je kunt afstemmen op 5.0, dan kun je 4.8 daar waarschijnlijk ook ontvangen en vice versa. Voor rotors nog wel lastig - je weet niet bij voorbaat of dat ook echt werkt, maar voor multi-lnb opstellingen is dat juist perfect.

Dat gaat prima, ook met een motor. Dat kan ik je uit ervaring vertellen.

Dat betekent dat dan in satellites.xml de "enige echte" juiste posities komen te staan, zonder afrondingen voor het gemak, en zo te lezen is dat de lijst die jij nu gebruikt.

Klopt.

Wil je een workaround? De volgende methode zorgt ervoor dat hij niet meer bijgewerkt wordt:

ipkg files tuxbox-common
(maak een kopie van die files, softlinks zijn vaak niet nodig. Je kunt ook met 7-zip kijken wat er in een ipk zit)
ipkg remove tuxbox-common
(zet de kopieen terug)

Nou, ik heb uiteraard liever een oplossing dan een work-around, maar voorlopig zal ik die gaan gebruiken. Tenminste: als ik precies begreep wat je bedoelt: ik moet met het handje die bestanden kopiëren en later terugzetten?

[WanWizard]

Natuurlijk is zo'n "user" hack wel in te bouwen. Maar ik voel daar niets voor, zolang ik geen echt vat op de onderliggende problematiek heb. Ik denk liever een weekje langer na, om dan met een robuuste oplossing te komen. Aangezien de tuxbox update maar 1x per week ofzo gebeurt, mag het niet zo'n megaprobleem zijn als je dan een paar keer met de hand moet corrigeren.

Milo, met alle respect: excuse me?

Mijn voorstel voor een juiste symlink, wat geen aanpassing aan enigma vereist en perfect voldoet aan de vraag, is een "hack", en enigma wijsmaken dat 28.5 eigenlijk 28.2 is (of andersom) is dat niet? Laat staan dat je dit robust kunt noemen. Je gaat dan allerlei assumpties maken over wat ik wel en niet kan of wil ontvangen.

Bovendien, de issue is nu juist dat wij een satellites.xml genereren op basis van niet correcte informatie. En dat iemand die dat wel doet/wilt last heeft van het feit dat onze foute lijst hun goede lijst overschrijft. En in plaats van de oorzaak van het probleem aan te pakken gaan we work-arounds hacken om de gevolgen onder de mat te vegen?

/me lost...

[Sjaaky]

> Dat betekent dat dan in satellites.xml de "enige echte" juiste positities komen te staan, zonder afrondingen voor het gemak, en zo te lezen is dat de lijst die jij nu gebruikt.

In dat geval zou je met een 'consumenten schotel' bij bijv. 28.2 en 28.5 2x dezelfde settings op moeten geven. Dat lijkt me eerlijk gezegd wel netst en daar hoeft ook niets voor geprogrammeerd te worden (hooguit de satgrabber )
Andere mogelijkheid is een instelbare equivalenten tabel maken (0.8=1.0, 28.5=28.2), maar dat lijkt me al een stuk problemen in de praktijk opleveren.

[WanWizard]

Allemaal leuk en aardig, maar het oorspronkelijke probleem blijft bestaan. Namelijk dat een update een file van de user overschrijft.

Er zijn b.v. ook legio gebruikers (waaronder ikzelf, maar ook vele lijstenbouwers) die in hun xml file alleen de satellieten hebben staan die bij de lijst horen, en niet de godganse lijst van zaken die buiten het bereik van mijn schotel liggen. Die file overschrijf je wel, en dat los je niet op met hacks in grabbers of enigma.

Laten we nu a.u.b. oorzaak en gevolg uit elkaar trekken, op de stoel van de gebruiker gaan zitten ipv op die van de dev, en het uiteindelijke probleem oplossen.

[MiLo]

Wat ik wil proberen te maken is het volgende:

- "satellites.xml" bevat de echte orbitale posities voor alle satellieten. Geen afrondingen dus. Dan is de "behoefte" om hieraan te sleutelen verdwenen, want er staat alleen nog een "universele waarheid" in.

- Enigma2 is slimmer dan voorheen. Als je -op welke wijze dan ook- een LNB op "5.0" hebt gericht, dan zal hij ook "4.8" daarop proberen te ontvangen. Ditto voor 28.5 en 28.2. Dus een in een multi-LNB opstelling maakt het helemaal niet uit of je de LNB op 28.2 of 28.5 configureert, of voor mijn part op 28.3...

- Heb je een rotor, dan zal hij "precies" op de eerstgevraagde satelliet mikken. Misschien heb je hier wel iets aan een tabel, want misschien is het beter dat hij naar 1.0 draait ook als je 0.8 bedoelde, of juist naar 0.9 om er mooi tussenin te mikken. Da's wat ik bedoelde met mijn eerdere opmerking over rotors, want als je een extreem grote schotel hebt van een metertje of twee, kon dit wel eens nodig zijn.

[gerard0610]

[KingOfSat en Lyngsat gebruiken verschillende posities voor een aantal satellieten. En de gegevens van KingOfSat zijn nu juist zo mooi, geheel automatisch, met Dreamset binnen te halen. En ja, ze zijn benaderd; hun reactie was, even heel kort samengevat: "wij hebben gelijk".

Inderdaad, hier zit hem de essentie.

Verder: geweldig dat iedereen constructief oplossingen probeert aan te dragen. Bedankt.
Inderdaad liever nu proberen om, vanuit de optie van een (niet gespecialiseerde) gebruiker, een structurele oplossing te vinden en daar de tijd voor te nemen dan snel een work-arround te maken die te moeilijk is voor de gewone gebruiker.

[WanWizard]

@milo,

Daar schiet je dus niks mee op, want het issue dat op tafel ligt los je er namelijk niet mee op, en dat is: zodra je gebruik maakt van een externe lijst dan wel een tools als dreamset, dreamboxedit, etc, dan krijg je, of je 't nu wilt of niet, de satellites.xml bij het installeren van de lijst meegeleverd. En die kan (om welke reden dan ook) wel eens volledig anders zijn dan de versie die wij er met de eerst volgende update overheen knallen.

Je zit dan niet op ingewikkelde fuzzy logic in enigma te wachten, maar op een oplossing die er voor zorgt dat de update met zijn vingers van mijn file af blijft.

Het gaat er mij niet zo zeer om dat die extern opgeladen lijst blijft werken als wij eigenwijs besluiten om onder water de users satellites.xml te vervangen, het gaat er mij om dat je mijn user file aan 't vervangen bent, en dat niet de bedoeling is. Als je dat probleem op lost, is iedereen blij en blijft het overal gewoon werken. Zonder fuzzy logic.

En die kun je oplossen met een paar simpele handelingen:
- onze file ergens anders neer zetten
- /etc/satellites.xml symlinken naar onze file
- alle andere symlinks gewoon naar /etc/satellites.xml laten wijzen

Installeert de gebruiker een eigen lijst (via download, andere feed, tarball, of dreamset/dreamboxedit), dan wordt de symlink in /etc overschreven met de custom xml van de user, die vanaf dat moment overal gebruikt wordt. Wij kunnen gewoon onze eigen file automatisch via de feed blijven updaten, daar heeft de gebruiker geen last van. Om het helemaal fail save te maken check dan even of /etc/satellites.xml bestaat bij het opstarten, en zo niet, maak die symlink aan. Dan ben je ook beveiligd tegen het verwijderen van die user file.

Probleem opgelost: 5 minuten werk.

[MiLo]

Zo heel anders kan die lijst niet zijn. Hij kan dan wel de astra2 ergens tussen de 28 en 29 graden proppen, als hij hem op 27 of 30 graden zet, heb je gewoon geen beeld meer.

Mijn voorlopige idee is om die satellites.xml van die dreamset tooltjes volstrekt te negeren. Want of je de BBC nou op 28.2, 28.4 of 28.5 hebt gestopt, dat maakt toch geen bal meer uit, dat lost hij onder water wel op.

Zoals ik al eerder schreef, die hele "jouw file/mijn file" discussie is politiek geleuter, zolang die uit een ipk komt, moeten alle updates ervoor ook uit een ipk komen. Elke oplossing met symlinks is gedoemd te mislukken voor een van de twee partijen, omdat dan ook de symlink wordt bijgewerkt als je een update draait.

Wil je het allemaal op file niveau oplossen, dan moet je met update-alternatives gaan werken. Maar daar zijn die dreamset tooltjes dan weer te stom voor. Eigenlijk hadden settinglijsten al via update-alternatives kunnen werken, maar daar heeft Dream weer een rare zet gedaan door allemaal losse filetjes te maken.

[VU+NL]

We zijn nu een weekje verder: heeft deze gedachtenexercitie een oplossing opgeleverd?

[VU+NL]

En vandaag is het dus weer gebeurd: de online update heeft weer "keurig" mijn eigen lijst overschreven. Jammer, heel jammer dat de automatisering hier echt te ver is gegaan. En dat bovenstaande discussie blijkbaar tot niets heeft geleid.

[gerard0610]

En vandaag is het dus weer gebeurd: de online update heeft weer "keurig" mijn eigen lijst overschreven. Jammer, heel jammer dat de automatisering hier echt te ver is gegaan. En dat bovenstaande discussie blijkbaar tot niets heeft geleid.

Jammer.
Misschien dat er toch eens op termijn ...... ?

[hemertje]

En vandaag is het dus weer gebeurd: de online update heeft weer "keurig" mijn eigen lijst overschreven. Jammer, heel jammer dat de automatisering hier echt te ver is gegaan. En dat bovenstaande discussie blijkbaar tot niets heeft geleid.

er is/was in onze automatisering niets aangepast al leek dat misschien zo te zijn de laatste tijd
de grabber bleek al enige weken niets meer automatisch 1x per week te draaien

verder is er met bovenstaande discussie nog niets gebeurd in onze vakantietijd

[VU+NL]

.....verder is er met bovenstaande discussie nog niets gebeurd in onze vakantietijd

Het is ook niet zo belangrijk of er al verbeteringen zijn doorgevoerd: het gaat me er voornamelijk om wat de plannen zijn. En of er überhaupt plannen zijn.

[hemertje]

.....verder is er met bovenstaande discussie nog niets gebeurd in onze vakantietijd

Het is ook niet zo belangrijk of er al verbeteringen zijn doorgevoerd: het gaat me er voornamelijk om wat de plannen zijn. En of er überhaupt plannen zijn.

nog niets gebeurd als in ook daar hebben we intern nog geen ei over gelegd....

persoonlijk heb ik geen moeite met de huidige situatie, wanneer ik wil scannen heb ik nu iedere week een up to date basislijst, maar blijkbaar hebben anderen daar moeite mee

het is maar net wat je als standaard referentielijst gebruikt, voor mij is dat dus onze sat.xml welke ook door Henksat gebruikt wordt

mbt de discussie Lyngsat / Kingofsat: welke site komt het meest overeen met de werkelijkheid want nu gebruiken we voor onze sat.xml en picons Lyngsat
en is KoS net zo goed gevuld met de picons aangezien ik lees dat sommige gebruikers meer gecharmeerd zijn van KoS dan van Lyngsat...

[littlesat]

Misschien nog een idee. De afwijkingen zijn maar 10-en in graden. Is het niet mogelijk om in een multifeed opstelling te zoeken naar een LNB die binnen een (instelbare) marge valt en deze LNB te nemen...En dan de positie te nemen die in de lamedb staat en niet meer naar de satellites.xml te kijken... en voor het draaien draaien zoals het in de lamedb staat?

[hemertje]

welke neem je dan als referentie, de middelste of de uiterste?
en hoe geef je dit aan?

[MiLo]

welke neem je dan als referentie, de middelste of de uiterste?

Geen van bovenstaande.

De LNB positie is de referentie.

Dus als je wil tunen op 28.5 en de LNB staat op 28.4, dan werkt dat voortaan.

Een rotor draait dan naar 28.5, en een 28.4 werkt dan ook nog. Een 28.2 dan misschien niet meer, moet je maar een fatsoenlijke lijst maken...

(en die 28.x getallen zijn betekenisloze voorbeelden...)

[gerard0610]

.....verder is er met bovenstaande discussie nog niets gebeurd in onze vakantietijd

Het is ook niet zo belangrijk of er al verbeteringen zijn doorgevoerd: het gaat me er voornamelijk om wat de plannen zijn. En of er überhaupt plannen zijn.

nog niets gebeurd als in ook daar hebben we intern nog geen ei over gelegd....

persoonlijk heb ik geen moeite met de huidige situatie, wanneer ik wil scannen heb ik nu iedere week een up to date basislijst, maar blijkbaar hebben anderen daar moeite mee

het is maar net wat je als standaard referentielijst gebruikt, voor mij is dat dus onze sat.xml welke ook door Henksat gebruikt wordt

mbt de discussie Lyngsat / Kingofsat: welke site komt het meest overeen met de werkelijkheid want nu gebruiken we voor onze sat.xml en picons Lyngsat
en is KoS net zo goed gevuld met de picons aangezien ik lees dat sommige gebruikers meer gecharmeerd zijn van KoS dan van Lyngsat...

Dat zou geweldig zijn. Maar..,, zoals ik al paar keer duidelijk heb proberen te maken, gaat mijn/onze voorkeur uit naar de posities van Kingofsat. Dit omdat ik/we vanuit hun database (m.b.v. DreamSet) op elk moment een lijst kunnen generen. Geweldig maar wel steeds problemen met de actualisering van Open-Pli (op basis van Lyngsat).

Veel mensen, die Openpli op hun ontvanger hebben staan, hebben deze er niet zelf opgezet en hebben geen achtergrond info omtrent de satellites.xml problematiek. Ik/wij krijgen veel klachten van deze 'gewone' Pli-gebruikers dat sommige zenders niet meer werken.

Ik hoop echt dat er moois uit kan ontstaan.

Hartelijk dank voor jullie werk. We genieten dagelijks van Open-Pli. Super.

[hemertje]

en van deze gebruikers verwacht je dan wel dat ze met dreamset hun zenderlijst gaan genereren?
ik neem aan dat deze ook een standaard zenderlijst , bv die van Henksat, op hun box installeren

ons/mijn inziens is wereldwijd de website Lyngsat de toonaangevende bron mbt satellietposities en hun verdere informatie, dat is de reden dat we destijds voor Lyngsat als bron hebben gekozen

[VU+NL]

.....ons/mijn inziens is wereldwijd de website Lyngsat de toonaangevende bron mbt satellietposities en hun verdere informatie, dat is de reden dat we destijds voor Lyngsat als bron hebben gekozen

Zoals in dit draadje al herhaaldelijk is aangegeven:
1- kan je dat niet zomaar stellen omdat Lyngsat duidelijk niet alle posities weergeeft, maar een aantal posities afrondt;
2- er zijn goede redenen om een "eigen" satellliet- en transponder database te willen gebruiken. Dat kan ook, behoudens het feit dat je vanaf dat moment niet meer kunt updaten. Daarmee beknot je gebruikers nodeloos in hun normale vrijheid.


Ik wil nog even de situatie memoreren zoals ik die van een andere ontvanger ken, en die wellicht ook bruikbaar is. Ook daar is een database "verstopt" in de firmware. Ook daar wordt bij een firmwareupdate die database ververst. Echter: indien een eigen database wordt gebruikt, wordt daarmee de "ingebouwde" database buiten gebruik gesteld. Op die manier neemt de gebruiker de leiding bewust over en wordt niet "lastig gevallen" door opgedrongen updates. Echter: op het moment dat de gebruiker daarvoor kiest, kan hij de in de firmware aanwezige database zonder enig probleem activeren.
Zou dat niet een voor iedereen bruikbare oplossing zijn?

Verder wil ik graag proberen de discussie zuiver te houden. Mijn punt als TS is dat ik geen updates opgedrongen wil krijgen als ik ervoor kies een eigen database te benutten. Dat is waar dit draadje over gaat.
In de zijlijn daarvan komen allerlei andere zaken naar boven. Geïnspireerd door het topic, komen er allerlei ideeën op om op een meer intelligente manier met een database om te gaan. Allemaal heel goed, een vruchtbare discussie voor zover ik dat kan overzien, maar die moeten ons niet laten afleiden van de hoofdzaak.
Als ze kunnen bijdragen het probleem op te lossen: prima.
Als ze kunnen bijdragen tot het fijnslijpen van andere, database gerelateerde zaken: prima.
Maar het hoofdpunt blijft: hoe ervoor te zorgen dat een gebruikersdatabase niet door updates wordt overschreven.

En: en passant heb ik een hoop interessante gedachten de revue zien passeren.