xxv bekommt nicht EPG-Daten nicht mehr auf allen Kanälen?!

Zitat

Original von docschneider
Sind die Änderungen in der EPG.pm ausreichend,

Hmm, xpix hat am 25. des letzten Monat schon den selben Lösungsansatz gepostet... http://www.vdr-portal.de/board…?postid=326022#post326022
wenn es denn funktioniert, sollte es wohl genügen.

Zitat

Original von docschneider
muss der typ noch an anderen Stellen von int zu unsigned int geändert werden?

Wenn, dann eigentlich nur noch im Modul RECORDS...

Da ich mit dem Thema keine Probleme mehr will, sind jetzt alle ID Felder
[PHP]Id int(16) unsigned ... ,[/PHP]
und hoffentlich damit groß genug.

Andreas

Dann will ich doch mal das große Geheimnis lüften. xpix hatte nur int(11) durch int(16) ersetzt. Die Zahl in der Klammer hat aber nur Einfluß auf die Anzahl der Decimalstellen bei der Ausgabe. Die interne Speicherbreite war weiterhin auf 31 Bit (<=0x7FFFFFFF) begrenzt. Die Berechnung von eventid liefert aber Werte bis 0xFFFFFFFF. Somit kam es in einigen Fällen zu einer Überschreitung des Zahlenbereichs und als Folge zu einer Fehlinterpretation der Zahl durch mysql.

Zitat

Original von nibbana
Dann will ich doch mal das große Geheimnis lüften. xpix hatte nur int(11) durch int(16) ersetzt. Die Zahl in der Klammer hat aber nur Einfluß auf die Anzahl der Decimalstellen bei der Ausgabe. Die interne Speicherbreite war weiterhin auf 31 Bit (<=0x7FFFFFFF) begrenzt. Die Berechnung von eventid liefert aber Werte bis 0xFFFFFFFF. Somit kam es in einigen Fällen zu einer Überschreitung des Zahlenbereichs und als Folge zu einer Fehlinterpretation der Zahl durch mysql.

Heisst das man kann sich den sprutz mit "int(11)" bzw. "int(16)" sparen durch ein einfaches "int" ersetzen ?
Wenn es nur für die Ausgabeformatierung relevant ist, denn die Ausgabebreite ist für xxv ehe vernachlässigbar.

Andreas

Theoretisch ist die Angabe hier überflüssig. Sinn macht sie zB. wenn man mit ZEROFILL die führenden Nullen einblenden will. Das gilt aber nur für die verschiedenen int-Typen. Bei char und varchar gibt der Wert die wirklich benutzbare Speicherbreite an. Ich glaube aber nicht das hier Nachteile entstehen. Laß es einfach wie es ist.

Never change a running system!

Immerhin, waren wir schon mal auf dem richtigen Dampfer. Nur die Lösung war die falsche. Danke an alle!

Tja, ich bin hier noch im Umzugsstress und (schlimmer) mein DSL Zugang lässt auf sich warten. Deswegen bin ich nur alle 3 Tage mal kurz online und schaue was xxv so bei Euch macht

@Hulk

Kannst du dem Tobi einen Patch schicken, so das er diesen noch für die c't Version mit einbaut?

Bis bald
xpix

leider muss ich hier noch mal was zu xxv nachfragen:

scheinbar klappt es bei mir, dass alle epg daten in der mysql datenbank landen, doch irgendwie werden diese nicht in xxv angezeigt.
Wenn ich auf Report klickte bekomme ich auch die Info, dass ich 29269 EPG Daten Einträge hab, doch ich bekomm davon nix zu sehen

nun weiß ich nich so ganz, wo ich anfangen soll nach einer lösung zu suchen...

Folgende log Einträge lassen mich ein wenig verzweifeln:

[CODE]
- Undefined subroutine &Template::Plugin::File::getwuip called at /usr/lib/perl5/Template/Plugin/File.pm line 104
- Config -> AUTOTIMER ->exclude: at /usr/share/perl5/vdr-xxv//XXV/MODULES/CONFIG.pm line 224
[CODE]

diese unfefinierte subroutine tauch irgendwie öfters auf...

evtl. kann ja jemand helfen?

Gruß
bensen

Hallo, ich bin's mal wieder!

Ich hatte in der letzten Zeit das Problem, dass nicht mehr für alle Aufnahmen die Preview-Bilder erzeugt wurden.
Darum habe ich ein bißchen gesucht und rumprobiert und siehe da:

Das Problem waren mal wieder die unsigned Integer. Ihr habt zwar in der Datenbank die ganzen Einträge auf int(16) unsigned erweitert, aber vergessen die sprintf-methoden entsprechend anzupassen.
Dort steht meistenst sprintf("...%d...", ...->{eventid})
%d ist natürlich hier wieder falsch, da %d signed int ausgibt. Bei mir werden die Previews für alle Aufnahmen erstellt seitdem ich alle %d in den o.g. Stellen in der RECORDS.pm auf %lu für unsigned long geändert habe.

Es ist meiner Meinung nach möglich das evtl. andere Bugs, die ich selber bei mir noch nicht festgestellt habe, auf das gleiche Problem zurückzuführen sind. Ich denke mal xpix und Hulk wissen am besten wo es da zu Problemen kommen kann. Also an dieser Stelle die Anregung an Euch: "Schaut doch mal nach, ob o.g. Problem noch an anderen Stellen zu Problemen führen könnte."

Ich hoffe das Posting hier kommt nicht als Kritik rüber. XXV rockt wie die Hölle! Ich find's hammergeil.
Außerdem ist es klar, dass mit einer Version 0.43 noch hier und da mit Problemen zu rechnen ist.

Noch was anderes: Wann läuft denn der svn-Server wieder?

Zitat

Original von docschneider

Noch was anderes: Wann läuft denn der svn-Server wieder?

Ich denke mal, das die Funkstrecke nach dem Höllengewitter etwas aus der bahn geraten ist. Wir arbeiten dran

Zitat

Original von docschneider
... %lu für unsigned long geändert ...

erledigt, in r370

BTW: aktuell ist der SVN Server wieder erreichbar...
Andreas