TTD Forum

Hallo,

nachdem ja weiterhin nach Bugreports gefragt wurde, hier eine kleine Liste:

1. Wählt man in der Timerliste (Sicht 6) einen Timer-Eintrag mit OK an, so kann dieser nicht wieder mit Exit verlassen werden. Es muss explizit das Feld EXIT ausgewählt werden, um wieder rauszukommen.
2. Lautstärkebalken kann nicht auf bunt umgestellt werden.
3. Die Zahl bei der Spulgeschwindigkeit (2x, 4x, 6x) ist extrem klein. Allgemein ist der Font recht klein gewählt, Wir sind relativ weit vom Fernseher entfernt und haben nun deutlich mehr Schwierigkeiten, die Texte, Infos und Einstellungen zu lesen, als beim Original-Topf. Teilweise ist auch der Kontrast der gewählten Farben nicht optimal.
4. Hat man den Play-Balken eingeblendet und geht auf die Dateiliste, fehlt ein ganzer Block der Grafik. An dieser Stelle kommt das Fernsehbild. Außerdem bleibt der Playbalken weiterhin da.
5. Scrollt man mit dem Play-Balken, (Vor-/Rückspultasten), gibt es ständig Konflikte mit der Info-Anzeige rechts oben. Fortlaufend erscheint ein Teil der Info-Anzeige (Senderlogo oder der dortige Zeitbalken) und die normale Navigation wird verlangsamt oder bleibt gar ganz stehen. Man muss dann die Spultaste loslassen und neu drücken. Öfters geht dabei der Play-Balken weg und man muss wieder lange drauf drücken, bis er sich erneut einblendet. Das ist etwas lästig.
6. Bug oder Feature? Man schaltet auf die Kanal-Sicht (Sicht 1). Blättert man nun zwischen den Sendern hin und her, erscheint der Sender immer mit der aktuellen Uhrzeit sichtbar. Auch wenn man auf einem Sender deutlich zu einer anderen Zeit gescrollt hatte. Ruft man jedoch mit i die Info zu einer Sendung ab, wird ab dann auf einmal die Uhrzeit dieser Sendung als Referenzzeit beim Rechts-/Linksblättern.
   
   Beispiel: Ich schaue um 10 Uhr fern, gehe auf Sicht 1. Egal auf welche Uhrzeit ich auf einem Kanal hoch oder runter blättere, wenn ich zu einem anderen Kanal wechsele, sehe ich wieder alles ab 10 Uhr. Blättere ich aber z.B. auf 22 Uhr und schaue dort die Info zu der Sendung an, dann sehe ich ab jetzt immer die EPG-Daten ab 22 Uhr auf jedem Sender, wenn ich den Kanal wechsele. Das ist inkonsequent. Entweder *immer* die Uhrzeit lassen, zu der man gescrollt hatte, wenn der Sender gewechselt wird, oder *immer* die aktuelle Uhrzeit nehmen.
7. Ich schaue im Timeshift, z.B. 20 Minuten zurück. Nun will ich den Rest der Sendung aufnehmen. Ich drücke auf den Record-Button und die Dauer wird auf 2 Stunden gesetzt. Wie kann ich hier den Rest der Sendung aufnehmen? Im Topf ohne iTina kann man durch erneuten Druck auf die Record-Taste zum Ende der aktuellen, zum Ende der nächsten Sendung oder eine beliebige Zeit aufnhemen. Das scheint hier nicht zu gehen.
8. Hängt evtl. mit vorherigem Effekt zusammen: Man kann bei einem H-Timer (Sofortaufnahme) nicht bis zum Ende der aktuellen Sendung aufnehmen?
9. Am Mittwoch habe ich auf 3-Sat die 6 Folgen von Ijon Tichy aufnehmen wollen. Also habe ich einen Tina angelegt. Kurioserweise wurden die Aufnahmen in zwei Abschnitte aufgeteilt: erst 2 Folgen und dann 4 Folgen am Stück. Es war kein nennenswertes Problem, da entsprechende Überlappung vorhanden war. Aber wie kommt das? Hätten nicht alle 6 Folgen in eine Aufnahme müssen? Oder alle 6 Folgen einzeln? Warum gerade 2 und dann 4? Möglicherweise spielt hier eine Rolle, dass die Folgen jeweils 15 Minuten gingen, was genau der Summe meines Vor- und Nachlaufs entspricht (5+10 Min).
10. Seit ich das TAP aufgespielt habe, reagiert der Topf deutlich träger. Tasten werden verzögert angenommen (z.B. Umschalten), ja ich meine sogar, dass Aussetzer bei der Wiedergabe passieren, wenn parallel aufgenommen wird. Ist das immer so oder ist da noch was Ungereimtes im Tasteninterpreter? Braucht das TAP auch nennenswert Rechenzeit, wenn man gerade keine Funktion davon aufruft?

Gruß,

Hagge

zu 8.
Kein Bug. Die record Taste startet eine Sofortaufnahme über 2 h, wie der Topf auch. belende ich aber Sicht1,2 oder die Infobox ein und drücke auf dem aktuellen Event die Rec. taste, wird dieses bis zu Ende aufgenommen.

gruß

StevieC

zu 1:
In den Settings gibt es einen Parameter "Verhalten bei EXIT in Eingabefenster" (oder so ähnlich). Hier kannst Du "Sichern" oder "Abbrechen" einstellen.

Ergänzung zu Punkt 10:

Wenn ich das Programm umschalte (mit P+/P-), dauert es etwa 1 Sekunde, bis der Umschaltvorgang startet. Und ebenso lange, bis jeweils die Ziffer auf dem Bildschirm erscheint wenn ich über die Zifferntastatur einen neuen Kanal eingebe. Also z.B. auf Programm 12 schalten: 1 drücken, nach 1 Sekunde kommt Ziffer 1 auf dem Bildschirm, 2 drücken, nach 1 Sekunde kommt auch die 2 auf dem Bildschirm. Das finde ich recht zäh, verglichen mit früher.

Außerdem wenn ich das Programm umschalte, dann wird zwar das neue Programm und die Info-Box auf dem Bildschirm angezeigt, aber die neue Programmnummer wird im Topf-Display erst dann sichtbar, wenn die eingeblendete Info-Box wieder verschwunden ist. Also erst mehrere Sekunden, nachdem schon das neue Programm läuft. Auch das ist verwirrend und würde eine Bedienung bei ausgeschaltetem Bildschirm nahezu unmöglich machen.

Kann man da noch was optimieren, dass es wieder flotter geht? Mir will es nicht in den Kopf, dass ein so flotter Prozessor da so lange dazu brauchen soll. Da kann man bestimmt noch softwaretechnisch was verbessern. Ich würde ja gerne helfen und zum Beispiel einen Blick auf die Tastaturroutinen werfen, wenn man mich nur lassen würde...

Gruß,

Hagge

hagge hat geschrieben:

dass ein so flotter Prozessor da so lange dazu brauchen soll.

Also so nett hat sich noch niemand ausgedrückt ...

Gruß

StevieC

hagge hat geschrieben:Kann man da noch was optimieren, dass es wieder flotter geht? Mir will es nicht in den Kopf, dass ein so flotter Prozessor da so lange dazu brauchen soll.

Firmware mit Gm-Patch patchen?

lt. r2-d2:

Another one from the output of the profiler is [Gm] GetMsg, which optimises one of the most commonly used low-level routines (and a related one). In fact, the profiler cannot show how much this is an improvement because the guts of it happen under interrupts, but the tail end of the routine (actually in the call to re-enable interrupts...) does feature very high, so it could actually make a really enormous difference (again!). In the main routine it replaces 8 multiplications with just a single one, and eliminates 93 of the 129 lines of code. It does a similar thing to the other, related routine.

Ich finde dass z.B. QT viel schneller "ein-fadet", Scrollen in JagsEPG ist IMHO schneller, und auch sonst reagiert der Topf IMHO viel schneller.

Sigittarius-E hat geschrieben:Firmware mit Gm-Patch patchen?

Wäre einen Versuch Wert. Wobei ich denke, dass man oft auch an der eigenen Software (sprich in diesem Fall dem TAP) was drehen kann. Ich programmiere beruflich jeden Tag mit Embedded Systemen und weiß, dass man da fast immer noch was an Geschwindigkeit rauskitzeln kann, indem man andere Datenstrukturen nimmt oder sonstige Optimierungen macht. Das gilt sogar für die "offiziellen" Treiber solcher Embedded Boards. Auch hier kann man häufig noch deutlich optimieren, ohne gleich auf unschöne Tricks zurückgreifen zu müssen.

Einige Beispiele:

• Statt eine Liste mit Werten zu durchsuchen, ob ein Wert enthalten ist, kann man die Liste stattdessen als Array anlegen und mit dem Wert als Index direkt darauf zugreifen. Braucht vielleicht etwas mehr Platz, weil auch ungenutzte Werte belegt werden müssen, ist aber oft deutlich schneller. Ich denke hier an die Tastaturtabelle. Statt also eine Liste mit möglichen Tasten zu durchsuchen, könnte man die möglichen Tasten in ein Array legen und mit dem Tastencode indizieren und so alle relevanten Informationen (aktiv ja/nein, zugehörige Routine, etc.) für diese Taste bekommen. Sowas ist komplexitätsmäßig gesehen ein Zugriff mit O(1), während das Durchsuchen einer Liste mit n Elementen im besten Fall O(log(n)) dauert, bei linearer Suche im Schnitt O(n/2).
• Durch Verwenden von Hilfsvariablen kann man sich oft den erneuten Aufruf von (möglicherweise zeitintensiven) Funktionen sparen, wenn man deren Ergebnis in der Hilfvariablen speichert. Oft fällt es gar nicht auf den ersten Blick auf, dass eine Funktion öfters aufgerufen wird, weil die Schleife so groß und unüberschaubar ist.
• In C zeigen oft Pointer in Strukturen auf andere Strukturen, wo es wieder Pointer gibt. Schreibt man jedesmal die Kette s1->s2->s3... hin, kann der Compiler i.a. nicht erkennen, dass sich in der ganzen Kette der Datenstrukturen zwischen zwei Zugriffen gar nichts geändert hat. Er muss vom Worst-Case ausgehen, dass eine Zuweisung dazwischen hier einen der Pointer verändert hat und berechnet darum die Kette jedesmal wieder neu. Durch Verwenden von zusätzlichen Pointern, z.B. struct s3 *p = &(s1->s2->s3) und nachfolgender Verwendung von p statt der Pointerkette kann man diesen Overhead deutlich verringern.
• Oft hat man eingeschachtelte if-Strukturen, die die Fehlerbehandlung etwas umständlich machen. Beispiel:
  

  Code: Alles auswählen

  tue was;
  if (success)
  {
      tue was;
      if (success)
      {
          tue was;
          if (success)
          {
             ....
          }
      }
  }

  Diese Schachtelung macht es oft schwer, den Fehler "nach oben" zu propagieren. In neueren Programmiersprachen gibt es hierzu das Konzept der Exceptions, aber in C eben nicht. Hier kann man sich z.B. durch einen Trick behelfen:
  

  Code: Alles auswählen

  do
  {
      tue was;
      if (!success)
          break;
  
      tue was;
      if (!success)
          break;
  
      tue was;
      if (!success)
          break;
  
      ...
  } while (FALSE);

  So ein Konstrukt lässt sich viel leichter bearbeiten und ist darum meist effizienter. Außerdem schachtelt es nicht so tief und ist darum wesentlich übersichtlicher.

Und so gibt es noch viele andere Beispiele, wie man Code optimieren kann. Auch gerade bei der (quasi-)parallelen Programmierung wie hier beim Topf mit Callbacks aus Interrupts u.ä. gibt es viele Fallstricke mit Race-Conditions oder Routinen, die unnötig oft aufgerufen werden, weil man zu wenig oder auch zu übervorsichtig synchronisiert. Im ersten Fall gibt es dann Bedienungsfehler, die mal auftreten und mal nicht (wie z.B. das Zusammenspiel mit dem Play-Balken) und sich schwer reproduzieren lassen. Im zweiten Fall wird der Code verlangsamt, weil zu häufig gewartet werden muss.

Das alles sind Beispiele, wo man zum Teil ganz extrem viel Zeit gewinnen kann. Man muss es nur konsequent durchziehen. Ich hatte den iTina-Entwicklern hier schon mal meine Hilfe in Form eines Code-Reviews angeboten, aber leider wurde dies abgelehnt, weil sie den Quellcode (zumindest noch) nicht rausgeben wollen. Kann ich bis zu einem gewissen Grad verstehen, auch wenn ich eher ein Verfechter der OpenSource-Entwicklung bin, was gerade bei solchen Projekten wesentlich effizienter funktionieren würde. Aber das bedeutet nun eben, dass ich solche Tipps nur theoretisch hier auflisten kann, statt konkret am Code optimieren zu können.

Gruß,

Hagge

[quote="hagge"]Wäre einen Versuch Wert. [/quote]

Würde mich interessieren ob der Gm-Patch bei dir merkbar was bringt. Vielleicht hast du ja mal Zeit ihn einzuspielen und zu vergleichen.

[quote="Sigittarius-E"]Würde mich interessieren ob der Gm-Patch bei dir merkbar was bringt. Vielleicht hast du ja mal Zeit ihn einzuspielen und zu vergleichen.[/quote]

Ich hab den jetzt mal bei meinem 6000er eingespeilt, aber bringen tut er nichts.

Gruß

StevieC

Ich mach jetzt mal bei von mir neu gefundenen Bugs in diesem Thread weiter und numeriere die neuen Bugs einfach weiter durch. Bringt ja nichts, ständig neue Threads zu starten. Der Bug hier ist neu:

11. Meine Platte war voll. Darum wurde eine Aufnahme nach 5 Minuten schon wieder abgebrochen. Zufällig kam ich noch während der Restlaufzeit der Sendung hinzu, merkte es und löschte die Datei gleich wieder. Jetzt kommt das Seltsame: Wenn nun die Infos rechts oben eingeblendet wurden, z.B. durch Druck auf die Sat-Taste, stand dort immer noch, dass eine Aufnahme aktiv ist. Das war erstens falsch und zweitens stand da nun der Event-Name "__temprec__ts" im Info-Feld. Dies scheint also ein Fall zu sein, der noch komplett nicht abgefangen ist.

Gruß,

Hagge

Ich füge das der Bugliste im Alpha-Bereich hinzu.

Wieder was:

12. In der virtuellen Tastatur fehlt der normale Punkt ('.'). Dies ist besonders blöd, da ja das ".rec" mit verändert werden kann. Wenn man also etwas an den Filenamen anhängen will, geht man auf den Punkt von ".rec", gibt ein Zeichen ein und stellt dann erst mal verärgert fest, dass man nicht eingefügt, sondern den Punkt überschrieben hat. Ab jetzt bekommt man den Punkt aber nicht mehr über die virtuelle Tastatur zurück, da er schlicht und einfach fehlt. Es geht zwar noch über die handy-ähnliche Tastatur, aber nicht über die normale. Oder bin ich nur blind?

Ansonsten wie schon mal angemerkt, wäre es besser, wenn die Tastatur "ringsum" ginge. Wenn man also beispielsweise auf einer Taste in der ganz linken Spalte ist, sollte ein Druck auf links zur ganz rechten Spalte wechseln und umgekehrt. Wie eben in der Originaltastatur.

Und das ".rec" sollte nicht veränderbar sein und darum auch erst gar nicht angezeigt werden. Ich kann mir keinen Fall vorstellen, wo das Ändern von ".rec" in was anderes sinnvoll wäre.

Gruß,

Hagge

zu 12. Ich werde die virtuelle tastatur nochmal überarbeiten. Die 6 leeren buttons waren mal zur erw. Eingabe gedacht. Seit dem es dafür aber eine extra Eingabemaske gibt, ist das überflüssig. Dann wird auch das zyklische Scrollen möglich sein.

Gruß

StevieC

hagge hat geschrieben:Und das ".rec" sollte nicht veränderbar sein und darum auch erst gar nicht angezeigt werden. Ich kann mir keinen Fall vorstellen, wo das Ändern von ".rec" in was anderes sinnvoll wäre.

Man könnte z.B. eine ImproBox-Papierkorb-Datei erzeugen (.del). Oder Filme vor Regierung oder Kindern verstecken .

Aber ich gebe dir Recht, ich sehe es auch so, dass die Endung .rec weder angezeigt noch geändert werden sollte.

Gruß, Horst

Mal wieder was:

13. Wenn die Platte komplett voll ist, zeigt die Fullanzeige/Restzeitanzeige in der Dateiliste auf einmal so an, als ob die Platte komplett leer wäre. (Vielleicht ein "geteilt durch 0"-Fehler?)

Gruß,

Hagge

[quote="hagge"]Mal wieder was:

13. Wenn die Platte komplett voll ist, zeigt die Fullanzeige/Restzeitanzeige in der Dateiliste auf einmal so an, als ob die Platte komplett leer wäre. (Vielleicht ein "geteilt durch 0"-Fehler?)

Gruß,

Hagge[/quote]

Kann ich so nicht bestätigen. Ich hab eigentlich immer ne volle Platte, aber das wird korrekt angezeigt. Welche Einstellung hast du? Ich hab min/h

Gruß

StevieC

Aber ist deine denn schon einmal komplett voll?

Gruß, Horst

macfan hat geschrieben:Aber ist deine denn schon einmal komplett voll?

Gruß, Horst

ich sag ja, fast jeden Tag.

Gruß

StevieC

[quote="StevieC"]Welche Einstellung hast du? Ich hab min/h[/quote]
Ich habe die durchwechselnde Einstellung.
Auf jeden Fall hatte ich gestern auf einmal einen vollen Balken, 156 von 160 GB frei und habe mich furchtbar gewundert (ja sogar erschrocken, weil ich geschwind dachte, alle meine Files seien weg). Nachdem ich eine Datei gelöscht habe, war aber wieder alles OK.

Gruß,

Hagge

[quote="hagge"]Ich habe die durchwechselnde Einstellung.
Auf jeden Fall hatte ich gestern auf einmal einen vollen Balken, 156 von 160 GB frei und habe mich furchtbar gewundert (ja sogar erschrocken, weil ich geschwind dachte, alle meine Files seien weg). Nachdem ich eine Datei gelöscht habe, war aber wieder alles OK.

Gruß,

Hagge[/quote]

Das ist in dere Tat merkwürdig. Aber ich probier das nachher mal. bei meinem Chronischen Platzmangel dürfte sich die Situation schnell nahstellen lassen.

Gruß

StevieC