[gelöst]epgd auf Debian-Wheezy auf der GoFlex (locales)

Was spuckt denn "locale" aus?

LANG=de_DE.UTF-8
LANGUAGE=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=de_DE.UTF-8

Quote from BooStar

Sollte da nicht was von utf8 in der ersten Zeile stehen?

Ja, aber nur, wenn du die Umgebungsvariable für LANG bzw. die locale entsprechend gesetzt hast.

Sep 09 21:52:47 alarm systemd[1]: Starting Epgd daemon...
Sep 09 21:52:48 alarm epgd[12923]: Set locale to 'de_DE.UTF-8'
Sep 09 21:52:48 alarm epgd[12923]: detected UTF-8

Probier doch mal dpkg-reconfigure locales.

locale-gen de_DE.UTF-8

Grüße
Martin

Wenn du die locale nicht fürs ganze system umbiegen willst reicht es aus die LANG variable nur im startscript des epg zu exportieren.

Quote from BooStar

Wie setze ich die denn richtig?

Aus einem bösen Wiki, das hier nicht verlinkt werden darf, aber einen netten Artikel zur Dockstar mit Debian hat:

Quote

Debian auf deutsch einstellen

Code

apt-get install locales language-env

Danach legt man den Standard-Locales des Systems fest mit:

Code

dpkg-reconfigure locales

vorzugsweise de_DE.UTF-8 dazu noch de_DE@euro

Jeder Nutzer, der seine eigene Locales dann definiert haben will, sollte

Code

set-language-env -R

ausführen. Das erzeugt Einträge in verschiedenen Text-Konfigurationsdateien. in ~/.bashrc :

Code

LC_MESSAGES=de_DE.UTF-8
   LC_CTYPE=de_DE.UTF-8
   export LC_MESSAGES LC_CTYPE

Display More

Quote from BooStar

Habe ich das richtig verstanden, das der Load "nur" beim Abfragen vom epg2vdr-plugin entsteht?

epgd greift auch auf die Datenbank zu. Der initiale Import dürfte das schlimmste sein, meine Dockstar mit Arch Linux ARM und MariaDB und einem Client mit epg2vdr steckt das alles bislang eigentlich ganz gut weg (ich habe aber mit zramswap für ein bisschen mehr Luft beim RAM gesorgt)...

# free
             total       used       free     shared    buffers     cached
Mem:        122988     120688       2300          0       2396      73820
-/+ buffers/cache:      44472      78516
Swap:        24596      23556       1040

Quote from BooStar

Derzeit läuft das Debian noch auf einem USB-Stick, die swap-Datei liegt allerdings auf SATA1.

Ich habe auch die Datenbanken auf eine HDD gelegt, dem USB-Stick mit dem System will ich das nicht zumuten.

Quote from BooStar

Aber um wirklich zu sehen was da los ist, brauche ich ja einen entsprechenden Client und irgendwie will ich vor meinem Urlaub meinen produktiv VDR nicht patchen (oder? das ist doch noch nötig solange vdr-2.0.3 noch nicht in testing ist, oder?)

Auch mit dem VDR 2.0.3 braucht es noch den epg-transfer Patch. Mir fehlt noch das Mischen der EPG-Einträge, vorher will ich das eigentlich auch noch nicht auf meinen Systemen regelhaft nutzen, aber für erste Tests sollte es reichen

krass wir ihr mit den kleinen Dingen fummelt

ja, ist wie Alex sagt: nix schlimmer als ne leere Datenbank - danach hält sich der Traffic in Grenzen. Dennoch bin ich verwundert, meine goflex hatte das damals nicht so gut verkraftet.

Danach schreibt das Plugin nur noch aktualisierte oder neue DVB Events zurück in die Datenbank, seit der letzten Version stoppen wir aus performancegründen dieses Rückschreiben während auch der epgd auf der Tabelle rumschreibt. Dadurch, und auch dadurch das nur noch ein client der Lieferung von frischem EPG zugeteilt, ist wird die Situation schon viel entspannter für den client. Auch der Fullupdate sollte nicht mehr bremsen weil auch während dieser Zeit der client angehalten wird, danach kommen bei ner leeren Datenbank naturgemäß erst mal viele DVB Events. - Da das EPG ja random über den Sender kommt ist das Anhalten des Cleints nicht weiter schlimm.

Christian

Quote from seahawk1986

Auch mit dem VDR 2.0.3 braucht es noch den epg-transfer Patch. Mir fehlt noch das Mischen der EPG-Einträge, vorher will ich das eigentlich auch noch nicht auf meinen Systemen regelhaft nutzen, aber für erste Tests sollte es reichen

Den werde ich in "unseren" (ya)vdr 2.0.3 einbauen.

Lars.

Quote from BooStar

Geil wäre natürlich folgendes: Am Beispiel von ARD (ca. 4 Wochen DVB-EPG):
ARD wird gemischt, hier werden die ersten 14-Tage von der externen Quelle betankt, und die restlichen 14 Tage kommen vom DVB-EPG.
Vergeht ein Tag (es ist also wieder 1 Tag mehr von der externen Quelle verfügbar wird dieser dann aktualisiert und das DVB-EPG hängt wieder einen Tag dran. Ist sowas möglich? Wobei das vom Thema abweicht

Provokant gefragt: was willst du haben, viel EPG vs. schickes EPG - oder schickes EPG vs. brandaktuelles EPG? Ich glaub viel EPG ist das worauf ich am besten verzichten kann

Das wird so wie du es beschreibst nicht sein, auch nicht mit Mischen, einfach weil wir es anders umsetzen als das andere erwähnte Plugin: epg2vdr wird immer getrieben und bestimmt von externem epg, angereichert um den Mehrwert des DVB EPG- in dem Fall aktuelle Programmänderungen, VPS Infos, die X Zeilen in der epg.data (wir nennen das Komponents), etc.

Es ist etwas abstrakt zu erklären, wenn wir etwas weiter im Testing sind erzähl ich ein wenig mehr dazu, aber du wirst nie EPG für eine Zeit weiter in die Zukunft haben als der ext Provider bietet. Es wird stattdessen genau umgekehrt sein wie du es dir wünscht: nach hinten raus pures ext EPG, und sehr nah am Sendetermin, also innerhalb der letzten 72h vor Ausstrahlung fangen wir aus das DVB event auszuquetschen. Wir werden auch noch bis zuletzt versuchen Aktualisierungen die der ext Provider bietet einzuarbeiten. - Andersrum macht es ja auch keinen Sinn, mW sendet HD+ bspw nur 3 Tage EPG.

Christian