BuGless

Heeft me wel eens 2 dagen gekost omdat ik dacht al wat gevorderd te zijn.....

Dat is het vervelende van "gevorderd"... Je kunt het pas beoordelen dat je het bent zodra je het bent; tot dan ben je nog niet gevorderd genoeg om te kunnen weten dat je het nog niet bent ;-).

In oscam zit cccam ook [ als ik het goed zeg ]

Niet precies (goed gezegd; maar goed, dat is min of meer een neveneffect van "nog" niet genoeg gevorderd zijn ;-). Het probleem is dat er naast de software ook nog communicatieprotocollen bestaan die diezelfde namen dragen als de programma's (lekker verwarrend). De programma's CCcam en oscam ondersteunen beiden een hele sloot aan protocollen, een van de protocollen heet CCcam en wordt inderdaad door beiden ondersteund.

Any other (important) issues on the WiP-list (to prevent useless reporting)?

The timeline bar at the top of the two GMEPG screens is being worked on. The idea is that it is transparent, but with black lining around the characters, and that the Pig shows through and the description too (on the normal GMEPG screen), and on the GMEPG-listmode screen, I'm still not quite happy with the useless space below the Picon and friends on the right.

It turns out though, that the layout of the timeline is currently being restricted by inadequacies in the C++ parts of enigma2. They're likely to be fixed within a week though.

Ahh, but manually editing files is not what I mean by 'scaling'. I thought scaling would be a GUI option. Or is that WiP as well?

That is WIP, yes, but not an option until other issues have been resolved first.

Actually all text in all screens is too far to the right. I didn't report that, as I have no idea how the 'scaling' will take place (I take it that this scaling is not yet available; is that correct?).

Partly.

You can (manually) simply change the following line to taste:

 <alias name="Overscan"   font="Regular" size="1"  height="20" width="10" />

The 10 means, that the skin currently leaves 10 pixels to the left and 10 pixels to the right "unused". If your texts are running off-screen to the right, increase it to 15 or 20 or 30, whatever you think looks best.
The 20 refers to the number of pixels skipped at the bottom and top, BTW.
The screen as such now, does not have a single lever to adjust overscan at the left and right sides independently. That would be easy to implement though.

In the PLi-HD skin the GMEPG has a nice 3dlook, is this possible in this skin too?

Yes. The GMEPG screens are being tuned as we speak, and the 3d look will be back after the tuning has been done.

Seems like I found a problem.
I cannot seem to reproduce the GMEG up/down navigation problem, however, I *am* able to spot the Single EPG missing channel name.

It appears that the ServiceEvent in GMEG does not cause a problem. However the renamed Service -> ServiceEvent member in EPGSelection is causing the missing channel name.
So, if you could please reapply the ServiceEvent addition to GMEG which appears to be harmless, but apply the following patch to EPGSelection instead, and can verify that nothing breaks (I tested it here with different skins and the TMDB plugin, and it appears to work), I'd be much obliged.

diff --git a/lib/python/Screens/EpgSelection.py b/lib/python/Screens/EpgSelection.py
index 6db8c32..5987e89 100644
--- a/lib/python/Screens/EpgSelection.py
+++ b/lib/python/Screens/EpgSelection.py
@@ -36,7 +36,7 @@ class EPGSelection(Screen):
  self["key_red"] = Button("")
  self.closeRecursive = False
  self.saved_title = None
- self["Service"] = ServiceEvent()
+ self["Service"] = self["ServiceEvent"] = ServiceEvent()
  self["Event"] = Event()
  if isinstance(service, str) and eventid != None:
  self.type = EPG_TYPE_SIMILAR
@@ -161,7 +161,7 @@ class EPGSelection(Screen):
  l.moveToService(self.session.nav.getCurrentlyPlayingServiceOrGroup())
  elif self.type == EPG_TYPE_SINGLE:
  service = self.currentService
- self["Service"].newService(service.ref)
+ self["ServiceEvent"].newService(service.ref)
  if self.saved_title is None:
  self.saved_title = self.instance.getTitle()
  title = self.saved_title + ' - ' + service.getServiceName()
@@ -350,9 +350,9 @@ class EPGSelection(Screen):
  datestr = '%s %d.%d.'%(_("Today"), begTime[2], begTime[1])
  self["date"].setText(datestr)
  if cur[1] is None:
- self["Service"].newService(None)
+ self["ServiceEvent"].newService(None)
  else:
- self["Service"].newService(cur[1].ref)
+ self["ServiceEvent"].newService(cur[1].ref)

  if cur[1] is None or cur[1].getServiceName() == "":
  if self.key_green_choice != self.EMPTY:

And you're not telling us??

I will release proper git patches, in due course. But if you are interested, the methods I added to the Button class are: connectDownstream(), checkSuspend(), disconnectDownstream(). After adding those, the widget (properly) collapses to zero size when unpopulated.

In looking for variations on the GraphMultiEPG I encounter various "mods" (BetterGraphMultiEPG, Coolguide, etc.) that basically all do the same thing, they are slight variations on the original theme, and fix some of the rough edges, but what I wonder about is: *Why* do these mods even exist? Why didn't they just contribute to the master source and fix the original?

The concept of Open Source normally is not just that you can fork it, the general idea is to contribute back instead; is there a reason why people in the enigma environment often seem to forget the second part?

die plugin overschrijft toch niet echt
/usr/lib/enigma2/python/Screens/ScanSetup.py hoop ik?

Backup gecheckt, en jawel hoor:

/media/backup/daily.0/tv2/var/lib/opkg/info# fgrep ScanSetup.py *

enigma2.list:/usr/lib/enigma2/python/Screens/ScanSetup.pyo
enigma2-plugin-systemplugins-blindscan.list:/usr/lib/enigma2/python/Screens/ScanSetup.py

Waarbij in de .py een referentie zit naar die DefaultWizard. Met als gevolg dat simpelweg verwijderen van die blindscan plugin het niet oplost (uiteraard).

Je kunt rsnapshot installeren op een willekeurige unix machine (Linux, MacOSX of anders). Het enige vereiste aan de OpenPLi kant is een werkende ssh toegang en rsync (rsync moet je meestal nainstalleren, zit niet in de standaard image).

Op je unix server installeer je crond en rsnapshot.
Maak een directory aan /var/media/backup (of een andere directory, daar waar de backups moeten komen).
Als root op je unix server maak met ssh-keygen een public key aan.
Append vervolgens de inhoud van de /root/.ssh/id_rsa.pub op de unix server aan de /home/root/.ssh/authorized_keys file op de OpenPLi box. Dat doe je op elke box waar je een backup van wilt maken.
Je kunt testen of je dit goed gedaan hebt, door handmatig ssh root@tv1.foo.bar te proberen als root op je unix server, als alles goed gaat kom je dan zonder wachtwoordvraag ingelogd op de OpenPLi box.

Vervolgens leg je op de unix server in /var/media/backup een file dreamboxsnapshot.conf aan met de volgende inhoud:

config_version 1.2
snapshot_root /var/media/backup
cmd_cp /bin/cp
cmd_rm /bin/rm
cmd_rsync /usr/bin/rsync
cmd_ssh /usr/bin/ssh
cmd_logger /usr/bin/logger
cmd_du /usr/bin/du
cmd_rsnapshot_diff /usr/bin/rsnapshot-diff
retain hourly 6
retain daily 7
retain weekly 4
retain monthly 3
verbose 2
loglevel 3
lockfile /var/run/rsnapshot.pid
ssh_args -p 22 -C
exclude /dev/*/*
exclude /media/*
exclude /proc/*
exclude /sys/*
exclude /var/volatile/*
exclude /tmp/*
link_dest 1
backup root@tv1.foo.bar:/* tv1/
backup root@tv2.foo.bar:/* tv2/
backup root@tv3.foo.bar:/* tv3/

Je kunt nu handmatig een test doen of de backup goed verloopt door de volgende commando's als root op je unix server uit te voeren:

cd /var/media/backup
rsnapshot -v -c dreamboxsnapshot.conf hourly

Vervolgens maak je op de unix server een file /etc/cron.d/rsnapshot aan met de volgende inhoud:

20 * * * * root cd /var/media/backup && exec rsnapshot -c dreamboxsnapshot.conf hourly
40 4 * * * root cd /var/media/backup && exec rsnapshot -c dreamboxsnapshot.conf daily
40 5 * * 1 root cd /var/media/backup && exec rsnapshot -c dreamboxsnapshot.conf weekly
40 5 1 * * root cd /var/media/backup && exec rsnapshot -c dreamboxsnapshot.conf monthly

Et voila! Je maakt nu automatisch een backup van 3 OpenPLi systemen (genaamd tv1.foo.bar, tv2.foo.bar en tv3.foo.bar) waar je uren, dagen, weken, maanden terug kunt; het maken van de backup zelf kost per keer niet veel langer dan een seconde of 2 (tenzij je net een update gedaan hebt, dan kan het iets langer duren).

Wat betreft overcommit, je zegt dat dat al uit staat op een openpli box. Toch lijkt het alsof ik zie dat op een box meer virtueel geheugen gealloceerd wordt dan dat er fysiek aanwezig is (op een DM500HD zonder swap). Dat zou dan toch eigenlijk niet mogen kunnen?

Hmmm, ik denk dat OpenPLi hier een duidelijk verbeterpunt heeft. Bij nalezen van de kernel docs blijkt dat de voor embedded/dedicated devices (zoals een OpenPLi systeem) de meest optimale instelling is:

echo 99 >/proc/sys/vm/overcommit_ratio
echo 2 >/proc/sys/vm/overcommit_memory

Dit is nl. de enige instelling die ervoor zorgt dat Linux niet speculatief meer geheugen toelaat om te alloceren. Aangezien het hier een gecontroleerde omgeving betreft (hoofdzakelijk enigma2), lijkt het me voor de hand liggen dat de kernel niet hoeft te liegen tegen enigma over de hoeveelheid beschikbare geheugen. Bijkomend gevolg is dat je verlost bent van het soort problemen dat "na een bepaalde tijd" zorgen dat de boel hangt, opnieuw start oid.

Een ander gevolg van deze instelling is dat, als je te weinig geheugen hebt om over langere tijd te blijven functioneren, je daar in een vroegtijdig stadium bericht van krijgt (omdat malloc() NULL teruggeeft, of omdat een programma bij het opstarten reeds zich beeindigd met de mededeling dat er te weinig geheugen is). Het is op dat moment dan duidelijk dat er swap bij moet, en hoeft dan dus ook niet meer geraden te worden naar een mogelijke oplossing van geheugentekorten die al naar gelang gebruik sporadisch en ogenschijnlijk random voorkomen.

Ik ga dit op m'n eigen systemen aanpassen in ieder geval.

sorry als de kritiek verkeerd overkomt maar we hebben toch maar een week problemen gehad doordat we met een nieuwe image gestart waren

Hetgeen betekent dat je 7 dagen lang verzuimd hebt om de problemen in detail te rapporteren op het forum, en dus anderen de kans ontneemt om in een vroegtijdig stadium te helpen, dan wel anderen de kans ontneemt om de OpenPLi software te verbeteren.

problemen zijn ondertussen opgelost, image 3.0 van beide decoders terug vervangen door image 2.1

Verkeerde woordkeuze, denk ik in dit geval. Problemen zijn niet opgelost; klinkt eerder als een Microsoft Windows oplossing (herinstalleren totdat het per ongeluk goed gaat).

... is het toch een teken dat er aan de decoders niets fout is maar dat de oorzaak in de software te zoeken is of dat er fouten zitten in de updates

Nee, dat is een voorbarige conclusie. Het is je overigens niet kwalijk te nemen dat je die conclusie trekt, betere conclusies zijn enkel mogelijk met meer kennis van zaken.
Maar dat is de reden waarom het verstandig is om in een vroegtijdig stadium in een dialoog te treden met de mensen op deze fora, op die manier kun je gebruik maken van hun kennis.

we zijn al een paar jaar vu+ gebruikers, omdat het nu eenmaal goede toestellen zijn, en we kijken ook regelmatig op het forum maar als we geen problemen hebben of hadden in het verleden is het toch niet nodig om berichten te posten niet?

Klopt. Maar op het moment dat je daadwerkelijk problemen hebt, wacht je blijkbaar te lang met het inschakelen van hulp.

binnen x aantal tijd geven we image 3.0 nog een kans, misschien zijn dan de eventuele software problemen opgelost, we wachten af.

Dat blijkt een fundamenteel probleem. Jullie schijnen niet te begrijpen dat OpenPLi een community-effort is. D.w.z. door enkel "af te wachten" garandeer je practisch dat de problemen *niet* opgelost worden. De grootste kans die je hebt dat de problemen opgelost worden is als je met het probleem in hand, je hier op het forum meldt, zodat we gezamenlijk en interactief met het probleem/de problemen kunnen kijken wat nodig is/was geweest om de problemen op te lossen c.q. te kunnen voorkomen in de toekomst.

In versie 1.7 Moet je het eerst zelf zetten met smartreader_settings17.exe het mag enkel 8 tekens lang zijn . Voor het bruikbaar te maken in oscam dient het de bestaan uit een reeks ascii tekens gevolgd door een spatie en dan een nummer. (de spatie geld als teken)

In alle oscam versies vanaf 30 januari 2012 is deze eis komen te vervallen, en werkt het ook met een korte naam zonder spaties.

Nope.

Maar die ga je dus nodig hebben om enigma aan de gang te krijgen.

Even snel googlend, zie ik een DVB API 3 dat in de kernel zou zitten, en een DVB API 5 dat deels in wording is; maar het zou te ver voeren als ik ook daadwerkelijk zou weten wie die versienummers bepaalt en in hoeverre dat betekent dat het bruikbaar is in combinatie met enigma2.

Wat je kunt doen is een lokale fork maken natuurlijk. D.w.z. met svn sources ophalen,

Of je gebruikt git. Het bijhouden van lokale patches is dan een peuleschil.
Je kunt gebruikmaken van mijn semi-publieke mirror van de subversion master van oscam.
Loopt nooit meer dan een uur achter bij de realiteit.

git clone git://git.cuci.nl/oscam

Dan aan de slag met je eigen patches, en vervolgens telkens "git fetch" en "git rebase" doen om bij te blijven (dat is wat ik doe).