xmltv import 1.0

[Gast MiLo]

Hij zal niet crashen, maar of hij dan toch geheugen inneemt durf ik eigenlijk niets over te zeggen.

[Gast pieterg]

-offtopic-

 

Origineel bericht van: zzzzzzz

TVE manuele scan = 1:0:1:2C5:7:1:FFFF014A:0:0:0:

 

Daar ben ik niet blij mee... Daar is het orbital position veld niet voor bedoeld.

Gaat ook grote problemen geven met picons enzo.

En met de autotimer (als je hem op specifieke services laat zoeken vindt hij wellicht niks, omdat de epg search alleen de eerste van de twee services vindt)

 

Heb je dat alleen als je per frequentie scant?

Of ook gewoon als je een volledige scan doet van je kabel tuner?

[Gast zzzzzzz]

Origineel bericht van: pieterg

-offtopic-

Origineel bericht van: zzzzzzz

TVE manuele scan = 1:0:1:2C5:7:1:FFFF014A:0:0:0:

Daar ben ik niet blij mee... Daar is het orbital position veld niet voor bedoeld.
Gaat ook grote problemen geven met picons enzo.
En met de autotimer (als je hem op specifieke services laat zoeken vindt hij wellicht niks, omdat de epg search alleen de eerste van de twee services vindt)

Heb je dat alleen als je per frequentie scant?
Of ook gewoon als je een volledige scan doet van je kabel tuner?

Ik moet nog eens checken wat hij er dan mee doet.
De frequentie van de VRT zenders (de meest interessante niet-geëncrypteerde kabelzenders dan nog !) zit echter op een locatie die met een automatische scan niet gevonden wordt.

Als je zegt "daar is het orbital position" veld niet voor bedoeld, wiens fout is dat dan ?
Van de originele Dreambox software makers ?

[Gast pieterg]

Origineel bericht van: zzzzzzz

Als je zegt "daar is het orbital position" veld niet voor bedoeld, wiens fout is dat dan ?
Van de originele Dreambox software makers ?

Ik denk het.
Ik neem aan dat je OpenPLi gebruikt, en wij hebben het in ieder geval niet bewust zo gemaakt (dan had ik dat waarschijnlijk geweest moeten zijn namelijk), dus ik neem aan dat het in dat geval iets is wat een van de dmm devs zo besloten heeft.
Maar het kan ook gewoon een fout in cables.xml zijn (al laten we die weg uit OpenPLi, omdat hij min of meer overbodig is)
Er zijn verschillende manieren om te scannen, dus ik ben wel even benieuwd of het bij alle gebeurt, of alleen bij een bepaalde manier van scannen.

[Gast zzzzzzz]

Origineel bericht van: pieterg

Ik neem aan dat je OpenPLi gebruikt

Inderdaad, ik gebruik Open PLi, maar ook in de vroegere PLi (toen ie nog niet open was had ik al dat probleem.
Mijn tuners zijn nu vrij, ik ga eventjes een automatische scan doen en zien wat hij doet.

Resultaat :
---------
Automatische scan met increment per 1 Mhz : zenders bevatten FFFF0xxx waarbij xxx de hexadecimale waarde is van de frequentie in MHz waarop die zit.

Automatische scan met vaste frequentiebanden : zenders bevatten FFFF0xxx waarbij xxx de hexadecimale waarde is van de frequentie in MHz waarop die zit.

Manuele scan van één transponder : zenders bevatten FFFF0xxx waarbij xxx de hexadecimale waarde is van de frequentie in MHz waarop die zit.

Cable scan : zenders bevatten FFFF0000

En inderdaad, voor alle zenders die met de cablescan gevonden werden, heb je dan geen picon, of je moet ze nog eens copiëren met de naam met FFFF0000.
Ook voor de EPG zou dit dus dubbel zoveel geheugen innemen, vermoed ik.
En Telenet heeft al sommige zenders 2 keer staan...

[Gast pieterg]

ik zal hetzelfde eens met ziggo proberen, mogelijk ligt het aan iets wat de provider in de sdt/nit stopt, mij is het in ieder geval tot nu toe nooit opgevallen (en ik heb ook nog niemand horen klagen over de ziggo picons, die allemaal met FFFF0000 zijn opgebouwd, en die hadden we al lang voordat we de cablescan hebben toegevoegd)

 

Als het iets is wat jouw provider meestuurt, kunnen we hier wellicht de cablescan op aanpassen, zodat hij die informatie ook meeneemt, en je ze de zenders in ieder geval niet meer dubbel hebt.

Mooi is het dan nog steeds niet, maar wel makkelijker wellicht dan juist alle andere enigma2 scan opties aan te moeten passen...

[Gast pieterg]

denk dat ik hem al zie, het is het gevolg van een enigma2 hack/workaround voor dubbele/ongeldige ONID's en TSID's

Om conflicten te voorkomen wordt in het namespace veld de frequentie meegenomen, voor een aantal situaties waarvan bekend is dat ze problemen hebben met dubbele nummers.

 

Jouw provider heeft toevallig ONID 1, en 1 staat op de zwarte lijst (behalve op 19.2 graden oost vreemd genoeg, daar is 1 wel geldig), dus krijg jij de frequenties erbij in het namespace veld.

 

Eigenlijk vind ik dat het een bug is om datzelfde lijstje voor cable (en eigenlijk ook terrestrial) te gebruiken.

Wat je nu krijgt is dat het resultaat willekeurig is.

Dus dat zou ik graag willen fixen, maar dat heeft dan tot gevolg dat al je picons gecorrigeerd moeten worden naar FFFF0000.

 

Ik denk dat ik dmm hier dan ook van op de hoogte ga stellen, hopelijk zijn ze het met mij eens, en dan zal uiteindelijk dezelfde piconset weer voor alle 'merken' images moeten gaan samenwerken als iedereen dezelfde fix doorgevoerd heeft.

 

Mee eens?

[Gast zzzzzzz]

Origineel bericht van: pieterg

denk dat ik hem al zie, het is het gevolg van een enigma2 hack/workaround voor dubbele/ongeldige ONID's en TSID's
Om conflicten te voorkomen wordt in het namespace veld de frequentie meegenomen, voor een aantal situaties waarvan bekend is dat ze problemen hebben met dubbele nummers.

Jouw provider heeft toevallig ONID 1, en 1 staat op de zwarte lijst (behalve op 19.2 graden oost vreemd genoeg, daar is 1 wel geldig), dus krijg jij de frequenties erbij in het namespace veld.

Eigenlijk vind ik dat het een bug is om datzelfde lijstje voor cable (en eigenlijk ook terrestrial) te gebruiken.
Wat je nu krijgt is dat het resultaat willekeurig is.
Dus dat zou ik graag willen fixen, maar dat heeft dan tot gevolg dat al je picons gecorrigeerd moeten worden naar FFFF0000.

Ik denk dat ik dmm hier dan ook van op de hoogte ga stellen, hopelijk zijn ze het met mij eens, en dan zal uiteindelijk dezelfde piconset weer voor alle 'merken' images moeten gaan samenwerken als iedereen dezelfde fix doorgevoerd heeft.

Mee eens?

Voor mij maakt het niet uit, of het nu allemaal met of allemaal zonder frequentie is, maar het zou wel interessant zijn dat ik ze maar één keer moet definiëren.
Hernoemen van die picons is niet zo moeilijk met een klassiek DOS commando
Ik was bezig met de EPG aan het testen, en zo kwam ik op die problemen terecht.
Dat had ik omzeild door die zenders er 2 keer in te zetten, maar dan krijg je een gigantische lijst.

Ik heb overigens nog een probleempje met PID's, en dat heb ik ook al van in het begin dat ik PLi gebruik.
Als ik bestanden heen en weer stuur tussen de Dreambox en Dreamboxedit, heb ik problemen met veel kanalen die niet beginnen met 1:0:1 (SD) maar bijv. met 1:0:2 (radio) of 1:0:19 (HD).
Ik zie in die fastscan lijst van TVV dan bijv. staan : 1:0:1... terwijl het toch een HD zender betreft.
Pas na manueel die transponder te scannen wil hij dan die zenders openen (kan ook om vrije zenders gaan als Das Erste HD).
De HD zenders die ik zelf toevoeg hebben dan wel 1:0:19... als begin.
Maar als ik dan een paar keer heen en weer FTP krijg ik errors en weet ik dat ze weer precies om zeep zijn.
En als ik die refs.txt produceer maakt hij van elke zender een 1:0:1 zender, of het nu SD, HD of wat dan ook is.

Nu weet ik niet, ligt dit aan PLi, of heeft het met de fastscan optie te maken of nog iets anders ?
Het is in elk geval niet aan de kabel gebonden.

[Gast zzzzzzz]

Eventjes een correctie : met een DOS commando is het eenvoudig om van FFFF0A16 (bijv.) naar FFFF0000 te gaan.

Omgekeerd natuurlijk niet.

Dus het lijkt mij interessanter om die Mhz die erin verwerkt zit weg te krijgen, dan om hem overal toe te voegen.

[Gast pieterg]

Origineel bericht van: zzzzzzz

Nu weet ik niet, ligt dit aan PLi, of heeft het met de fastscan optie te maken of nog iets anders ?

De servicetypes staan onjuist in de fastscan data van TVV (en CDS heeft volgens mij hetzelfde probleem)

Ik heb daar bij het zappen nog geen problemen mee ondervonden, maar krijg bijv bij BBC HD wel een probleem met autotimers die specifiek alleen op BBC HD mogen zoeken.
Ik moet dan verplicht de eerste variant uit m'n lamedb opgeven, en dat is de 1:0:1 uit de fastscan. Anders vindt hij niks.

CDS en TVV zouden eigenlijk de correcte servicetypes in de fastscan data moeten opnemen, in plaats van fixed 1 voor tv zenders, om deze problemen te voorkomen.

[Gast pieterg]

Origineel bericht van: zzzzzzz

Dus het lijkt mij interessanter om die Mhz die erin verwerkt zit weg te krijgen, dan om hem overal toe te voegen.

Mij ook, maar dan om een andere reden; namelijk dat die frequentie standaard altijd weggelaten hoort te worden, tenzij de provider slordig is en dubbele nummers gebruikt. Aangezien dat bij cable providers niet het geval zal zijn, is het niet logisch om op foute aannames toch die frequentie te gaan toevoegen.

Ik ga hem weglaten, ik denk nog even over de netste manier om dit te fixen, zodat dmm als het goed is geen redenen zal hebben m'n fix te weigeren.

[Alex1970]

Origineel bericht van: zzzzzzz

Eventjes een correctie : met een DOS commando is het eenvoudig om van FFFF0A16 (bijv.) naar FFFF0000 te gaan.
Omgekeerd natuurlijk niet.

Gebruik anders het freeware programma A.F.5 Rename your files.
Simpel maar doeltreffend.

[Gast pieterg]

Origineel bericht van: Lexzie

Origineel bericht van: zzzzzzz

Eventjes een correctie : met een DOS commando is het eenvoudig om van FFFF0A16 (bijv.) naar FFFF0000 te gaan.
Omgekeerd natuurlijk niet.

Gebruik anders het freeware programma A.F.5 Rename your files.
Simpel maar doeltreffend.

niet aan de orde, ik heb het al doorgevoerd

[Gast zzzzzzz]

Origineel bericht van: pieterg

Origineel bericht van: Lexzie

Origineel bericht van: zzzzzzz

Eventjes een correctie : met een DOS commando is het eenvoudig om van FFFF0A16 (bijv.) naar FFFF0000 te gaan.
Omgekeerd natuurlijk niet.

Gebruik anders het freeware programma A.F.5 Rename your files.
Simpel maar doeltreffend.

niet aan de orde, ik heb het al doorgevoerd

Om eventjes een Nederlandse reclameslogan te citeren "Dat was snel !"...
Bedoel je dat het in de laatste nachtelijke build al zit, of dat het doorgegeven is aan DMM ?

[Gast pieterg]

Origineel bericht van: zzzzzzz

Bedoel je dat het in de laatste nachtelijke build al zit, of dat het doorgegeven is aan DMM ?

Het had in de nachtelijke build moeten zitten, maar die build loopt nu pas in plaats van afgelopen nacht, dus nog een paar uur geduld.
En het is aan dmm doorgegeven.