deleted

Na het lezen van deze post (https://forums.openp...spelen-streams/) met entertainment waarde van de bovenste plank....heb er van genoten.

Na jarenlang OpenVIX gebruiker te zijn geweest, liep ik een tijdje terug tegen een probleem dat OpenVIX niet langer werkte op een ET-9500. Na 3 her-installaties, had ik geen andere optie voor ogen dan OpenPLI te installeren.

En wat blijkt nu: HET WERKT GEWOON

Eenvoudige image zonder toeters en bellen of ander onnodig spul.

Bij deze mijn appreciatie voor jullie harde noeste arbeid en onthoud, aan zeikers is er helaas geen tekort in deze wereld.

Om te beginnen graag niet weer beginnen over een Media Speler.

 

Het afspelen van DVD-Video gaat niet goed (VOB/VIDEO_TS), te eerste werkt het menu vaak niet. Als ik een item aanklikt start het niet of gaat dit tergent op gang.

Als ik stop druk gaat hij terug naar de file lijst. Ik zou liever zijn dat die daarmee terug gaat naar het DVD menu. (en mischien kan de echte menu knop dan voor het normale menu gebruikt worden)

Ik dacht er trouwens ook aan om 2,4,5,6,8 als menu navigatie te gebruiken (2 is pijl omhoog, 4 is pijl links, 5 is OK, 6 is rechts, en 8 is pijl beneden. En mischien een optie de DVD zonder menu te bekijken aangezien dat vaak problemen geeft.

Misschien moet het PLI team een VHS optie inbouwen, met VHS heb je al die rariteiten niet, gewoon PLAY en kijken.

When adding +1 to a logo for example in a "Sky Movies" font, if the text isn't converted to a path, the server that builts the picons, uses one of the fonts that are available, resulting in a poor logo with perhaps a +1 written in Times New Roman.

Some logos that use a more common font, can still contain text by default, it might look OK on a desktop, but if the server misses the font, same poor result.

Best practise: always convert to path, when building it should prompt that some logos contain text, so if you always to a test build before submitting a PR, all should be good.

I'll quickly add this:

hbo2nl.png is not going to be accepted as valid, you should use something like "-trechuhipe" (see: https://github.com/p...e-password.com)

The reason:

We've got channels called:

MTV Germany

MTV Austria

MTV UK

MTV Radio Germany

First two share a logo the others do not, with the old way of using country codes, could cause problems....

@Ocram,

Staan deze picons niet meer, of nog niet op Github?

Hehe, duurde even, maar ze staan erop.

Ik had juist het liefst de tar's gezien, met symlinks, daarmee kun je met een recipe dan vrij gemakkelijk een package maken.

Kun je dan niet even de ipk uitpakken en vandaar verder, zit namelijk hetzelfde in aan picons

ar -x enigma2-plugin-picons-tv-100x60.reflection-black_*_all.ipk | tar -zxvf data.tar.gz

Laatste release staat online op https://github.com/p...source/releases

Graag zou ik even onder de aandacht willen brengen dat vanaf nu er een eigen domein naam is: www.picons.org

De bestanden zijn ook niet meer te downloaden via GoogleDrive, maar gewoon rechtstreeks met normale url's.

Indien er wijzigingen zijn geweest, wordt automatisch om 0:00 iedere dag een nieuwe build gestart.

Er zijn nu wel wat maandelijkse kosten voor de VPS en domeinnaam, dus het success zal afhangen van het aantal donaties...

Maak je geen zorgen -Dennis-, je hebt in mijn ogen niks verkeerd gedaan en zoals jij gebruik maakt van de feed, denk ik niet dat daar iemand om hoeft te klagen...

 

Als men natuurlijk standaard het ocram-feed.conf zou gaan toevoegen aan OpenPLI, dan zal dit natuurlijk wel de nodige bandbreedte verbruik opleveren, waarvoor world-of-satellite dan zou opdraaien, wat niet eerlijk zou zijn tov hen, denk dat je het meer in die richting moet bekijken en niet persoonlijk opvatten, ook al bedoelde je deze manier niet expliciet....

 

 

That was my point. individual users taking the feeds is fine but to offer our feeds for use to another image without asking us is just not on, we pay for those feeds and if another image decides to incorporate them there basically stealing from us ( no i'm not accusing pli but i hope you can see where i'm coming from ).

Goed, ik denk dat we hier allemaal op dezelfde golflengte zitten, en zoals pheonix aahaalt, is dat idd geen nette manier tov andere teams...

Maak je geen zorgen -Dennis-, je hebt in mijn ogen niks verkeerd gedaan en zoals jij gebruik maakt van de feed, denk ik niet dat daar iemand om hoeft te klagen...

Als men natuurlijk standaard het ocram-feed.conf zou gaan toevoegen aan OpenPLI, dan zal dit natuurlijk wel de nodige bandbreedte verbruik opleveren, waarvoor world-of-satellite dan zou opdraaien, wat niet eerlijk zou zijn tov hen, denk dat je het meer in die richting moet bekijken en niet persoonlijk opvatten, ook al bedoelde je deze manier niet expliciet....

In der tijd is de ftp storage mij aangeboden om de ipk's makkelijk te kunnen aan bieden aan OpenVIX, hieruit is dit verder geëvolueerd naar de uiteindelijke feed constructie... mocht het VIX team zich hier niet langer in kunnen vinden, dat een enkeling zich er op deze manier van gebruik maakt, dan mogen ze me dit ook laten weten.

Misschien kunnen we ocram vragen een tar of een zip te maken van alle ipk's en die aan een vaste url te hangen.

Zover ik weet wilde hij dat niet doen.... Achteraf was dat denk ik een verkeerde keuze geweest van hem.

Maar zover ik begrepen heb heeft Radxnl er al wat op gevonden en moesten we geduld hebben.

AUB, geen leugens vertellen.

Dit is mij nooit gevraagd geweest, wel is mij ooit gevraagd geweest of dat ik niet iets anders wilde gebruiken dan Google Drive of Dropbox, waarop ik heb geantwoord, dat indien iemand mij de nodige ftp storage zou doneren, dat ik dit met alle plezier zou doen, maar toen werd het stil. Ik moet het doen met wat er voor mij gratis beschikbaar is en voor mij is Google Drive hierin het gemakkelijkst.

Achteraf gezien is dit tot op heden nog altijd de juiste keuze gebleken.

Er is in feite niet veel veranderd, buiten dat ik ben overgeschakeld van GitHub naar Bitbucket en dat dus de url gewijzigd moet worden waardat jullie de pagina inlezen met de downloads, dus als jullie het volgende doen:

dit:

http://ocram.github.io/picons/downloads.html

vervangen met dit:

http://picons.bitbucket.org/downloads.html

Dan moet het volgens mij gewoon weer werken.

En waarom GitHub vervangen werd door Bitbucket, komt omdat GitHub svg bestanden enkel als tekst laat zien en niet als afbeelding, Bitbucket doet beide, en een plaatje zegt mij meer dan 1000 woorden, vooral handig als je een PullRequest moet mergen. Maar het was denk ik ook veel beter geweest als jullie direct uit de feed hadden gedownload, die url blijft altijd constant en de inhoud van Packages normaal ook. Maar goed maakt in principe niet zoveel uit, ik ben ook niet van plan om het wekelijks te wijzigen.

Voor diegene die graag technische details weten:

-Picons die niet gebruikt worden, zitten niet langer in de release

-Er zitten geen "niet bestaande" servicerefs meer in

-Op aanraden van iemand, zitten alle afbeeldingen nu gescheiden van de symlinks

-De serviceref wordt automatisch aangemaakt zoals deze voorkomt in lamedb, voor fastscan lijsten wordt ook 1_0_1 aangemaakt, zodat diegene zonder fallback ook terug Picons zien

-Er wordt nu ook gebruik gemaakt van svg bestanden als vertrekpunt

-Er is nu een status pagina (http://picons.bitbuc...b_vs_picons.txt) waarop alle kanalen te zien zijn die momenteel ondersteund worden en hoe deze gelinkt zijn aan een picon

-Er wordt dus niet langer in het wilde weg servicerefs toegevoegd, eerst moet er een regelmatig onderhouden lamedb zijn, waartegen alles gecontroleerd kan worden

-Op de changelog pagina kan men nu per build zien wat er gewijzigd is

-Bij "Recent Changes" kan men de wijzigingen zien die nog niet zijn meegenomen in een build

-picons.sh is nu omgedoopt naar tv.srindex en radio.srindex, de inhoud hiervan is zoveel mogelijk vereenvoudigd, om het werken ermee te vergemakkelijken.

-Samen met de status pagina waarop direct met copy/paste de juiste serviceref te kiezen valt, is dit een pak eenvoudiger.

-De eerder verwijderde ondersteuning voor DVB-C en DVB-T is terug, mits regelmatig onderhouden lamedb wordt aangeleverd

-tal van wijzigingen in alle scripts om user errors op te speuren

-Bijna elk kanaal van 28.2, 23.5 en 19.2, 13.0 deels(heeft nog wat werk nodig), is door hulp van arno34 van een picon voorzien.

Dit moet het ongeveer wel zo'n beetje zijn wat er de afgelopen maand allemaal gewijzigd is.

Trouwens als je zelf nu eens een klein beetje moeite zou doen hé en de "status" pagina op http://picons.bitbuc...b_vs_picons.txt eens zou bekijken, dan weet je hoe het ermee staat.

Waarom meent toch iedereen dat ze de pap in de mond moet worden gegeven?

Wanneer gaat men eens leren dat ik die picons voor MEZELF in de eerste plaats maak, en het resultaat deel ik kosteloos met de wereld, niet omgekeerd.

Wanneer gaat men eens leren dat het OpenPLI team een image maakt omdat ZIJ dat leuk vinden, en het resultaat daarvan delen zij kosteloos met ons.

Soms heb ik de indruk dat men dit allemaal maar als vanzelfsprekend vindt, en dat iedereen die iets aanlevert/doet dat maar zo snel mogelijk moet fixen...Ik weet niet hoe anderen hierover denken maar het lijkt er steeds meer en meer op dat men eist dat alles probleemloos werkt.

Ik begin dit zo kotsbeu te worden, dat het zelfs al eens in me opgekomen is om slechts enkel diegene die ooit iets hebben bijgedragen in welke vorm dan ook, enkel nog maar een download link te bezorgen. Want niemand betaalt mijn bandbreedte hoor, buiten ikzelf.

Kortom ik ben hier nu al 3 uur kwijt met nutteloze posts, had jij nu even onmiddelijk, een inspanning geleverd, ipv liever lui dan moe te zijn, dan had jij ondertussen WEL picons gehad voor die kanalen en nu NIET.

Als jij even versie 2013-12-07--14-36-24 installeert dan is het opgelost. Ik begon die vragen toch wel kotsmoe te worden, dus heb het maar opgelost...

Enkel degene die nu kanalen lijsten gaat gebruiken die van KingOfSat afkomen gaat op zenders met serviceref 1016, want KOS maakt er 1019 van, wel nog problemen hebben als ze een image gebruiken zonder fallback. Maar met deftig gescande lijsten, geen probleem meer.

Dat kan toegevoegd worden, maar dan moet de lamedb ergens gemakkelijk toegankelijk beschikbaar worden gesteld op telkens dezelfde url en niet in een zip, achter een captcha, op een forum of dergelijke, dit moet dan ook regelmatig worden bijgewerkt en dan pas kan men door middel van een PR op bitbucket de nodige servicerefs toevoegen, verdwijnen er dan servicerefs dan kan dit automatisch worden gedetecteerd en naargelang gehandeld worden.