SmartSkipper Pro

[flechumer]

[quote=""fritschi""]Jetzt bin ich verwirrt. Ist es nicht umgekehrt das bei Blockausrichtung eigentlich nicht dort geschnitten wird wo man den Schnitt setzt sondern bei Clusterausrichtung. Ich verwende eigentlich immer die C-Ausrichtung da die ja genauer schneidet. Kann es sein das der Schnitt zwar genauer ist (clustergenau), bei der Wiedergabe aber der Topf doch auf Blockgrenzen springt und damit nicht ganz am Anfang nach dem Schnitt startet.[/quote]
Lass Dich nicht irritieren. Bei Blockausrichtung kann man zwar feiner einstellen, überlässt die Auswahl der Clustergrenze aber SSP. Wenn Du es also gewohnt bist, von vornherein auf Clustergrenze einzustellen: bleib dabei.

Frage: Gestern ist mir folgendes aufgefallen. Nach dem Start einer Wiedergabe war SSP aktiv und hat somit auch die >> und die <<-Tasten abgefangen. Wollte nur mal schnell etwas vorspulen und da erschien die SSP-Anzeige und der Balken fing an zu laufen. Ich konnte den schnellen SSP-vorlauf nicht stoppen (welche Taste?) und ich erhielt zwischendurch keine aktualisierten Bilder? Ist das normal oder deutet das auf eine zu langsame Festplatte hin.

Nein, die Festplatte hat damit nichts zu tun. Die Bilder wechseln alle 750 ms. Das ist nicht allzu schnell, besonders wenn man auf etwas wartet. Das ist leider technisch bedingt, kann ich also nicht ändern. Wahrscheinlich arbeitest Du noch mit der Voreinstellung von 4 Sek. Spulzeit. Damit ist eine Aufzeichnung natürlich ratzfatz durchgespult, während in der Zeit nur fünf Einzelbilder angezeigt werden. Ich komme mit 8 Sek. ganz gut zurecht. Anhalten kannst Du mit PLay oder OK. Es geht aber auch eine Richtungsumkehr mit Forward bzw. Rewind.

P.S. wollte nur mal melden das SSP-Pro wunderbar funktioniert und ich in letzter Zeit keinerlei Probleme hatte.

Na das hört man doch gern. : Von Dir und anderen SSP-Usern würde ich gern mal hören, welche Erfahrungen bisher mit Probability Control gemacht wurden. Zur Erinnerung: Das ist die Funktion, die das Überspringen von Werbung beschleunigt und wodurch sich SSP signifikant von anderen Methoden mit Binärsuche absetzen soll.

[fritschi]

Ich habe den Eindruck das beim Setzen der Marke 2 (Anfang erster Werbeblock) und dem nachfolgendem Springen die Stelle Marke-3 besser als früher gefunden wird. Da ich aber den SSP-Pro fast immer mit Echtschnitt verwende muß ich trotzdem mit Vorwärts Rückwärts die richtige Stelle finden. Rein subjektiv geht das nicht schneller als mit der 3er-Version da ich ja wenn ich bereits mit dem ersten Sprung nahe am Ziel bin mit dem zweiten ja wieder weiter weg springe. Mit der Funktion Sprungweite ändern hab ich mich noch nicht beschäftigt (habs mir halt ohne angewöhnt). Was für mich die tollste neue Einführung mit SSP-Pro ist, ist die Anzeige des Schnittbalkens unten in der Anzeige. früher ist es mir 2x passiert das ich bei einem Film mit vielen Werbeunterbrechungen nicht die letzte Werbung sondern den letzten Teil des Films weggeschnitten habe.

mfg fritschi

[Dixie]

Hi Rudolf,

Könnte dies eventuell auch die "Echtschnitt"-Abbrüche bei Smartskipper auslösen? Key-Event "Exit" z.B.

Nein. Ich mache eigentlich keine Key-Events.
Nur, wenn der gelbe Balken eingeblendet ist und man die "File-Taste" drückt.

Könnte dies die Abbrüche erklären?

Dixie

[flechumer]

[quote=""Dixie""]Könnte dies die Abbrüche erklären?[/quote]
Definitiv ja. Ich zitiere mal aus der neuen SSP Kurzbeschreibung (die noch nicht online steht).

10. Fehlersuche
---------------

Bei der Benutzung von SSP können - wie bei jedem komplexen Software-System - verschiedenartige Fehler auftreten. Um der Ursache solcher Fehler näher zu kommen, empfiehlt sich eine bestimmte Vorgehensweise. Zunächst sollte man alle anderen TAPs außer Betrieb nehmen. Tritt der Fehler nach Reboot dann immer noch auf, ist zu prüfen, ob die SSP-Version mit der Firmware-Version zusammenpasst. Ferner sind die eingestellten Parameter und Kommandozuordnungen zu prüfen. Bei einigen Modellen steht nicht die gesamte Auswahl an FB-Kommandos zur verfügung. Kann der Fehler auf diese Weise nicht gefunden werden, ist eine entsprechende Meldung an mail@flechumer.de wünschenswert.

Stellt sich bei diesem Vorgehen heraus, daß der Fehler bei Alleinbetrieb von SSP nicht auftritt, sollte man folgende Überlegungen anstellen. SSP benutzt die FB-Kommandos <ok> (nur bei Wiedergabe) und <forward>. Funktioniert die Aktivierung mit <OK> nicht, so ist davon auszugehen, daß ein anderes TAP, welches in der Ladereihenfolge vor SSP liegt, <ok> blockiert. Das Gleiche gilt für solche SSP-Kommandos, die während der Aktivität wirksam sein sollten aber nicht ausgeführt werden. Alle diese Fehler werden dadurch verursacht, daß ein anderes, in der Ladereihenfolge vor SSP liegendes TAP, das Kommando blockt. Hier hilft es, das verursachende TAP hinter SSP zu legen. Eine andere Möglichkeit besteht darin, die geblockte Funktion auf ein anderes FB-Kommando zu legen.

Bei SSP gibt es drei Funktionen, die relativ komplexe Funktionsabläufe nach sich ziehen. Dies sind:
(1) Echtschnitt
(2) Aktivierung aus Live-Zustand
(3) Umwandlung von Bookmarks in SSP-Schnitte
Dabei werden jeweils eine Vielzahl von FB-Kommandos abgesetzt, ganz so, wie wenn die entsprechende Funktion von Hand bedient würde. Die Kommandos sind: <play>, <stop>, <pause>, <ok>, <exit>, <prev>, <next>, <white>, <blue>, <v->, <v+>. Wird auch nur ein einziges Kommando während eines Ablauf von einem anderen TAP geblockt, kommt es zu einer Störung. SSP versucht solche Blockungen zu entdecken, was aber nur dann gelingt, wenn sie in der Ladereihenfolge vor SSP stattfinden. In einem solchen Fall, wird eine entsprechende Abbruchmeldung ausgegeben, sonst sind die Folgen nicht vorhersagbar.

Das Eintreffen unerwarteter Kommandos während eines komplexen Funktionsablaufs wird stets bemerkt und führt mit einer entsprechenden Meldung zum Abbruch und zur Blockung des Kommandos.

[Elle4u]

[quote=""flechumer""]Definitiv ja.[/quote]
Wieso?

Es wird doch nicht "Fileliste" simuliert, oder?
Und nur dann passiert in Filer etwas. Und auch nur dann, wenn der Status nicht "normal" ist.
Sobald Du also Exit_normal aufrufst macht Filer gar nix mehr!

Code: Alles auswählen

      if (param1 == RKEY_PlayList)
      {
        //Keine Reaktion, falls schon etwas angezeigt wird.
        if (mainState != STATE_Normal || subState != SUBSTATE_Normal)
        {
          //Falls nur der Fortschrittsbalken angezeigt wird, blende diesen aus
          if (mainState == STATE_Normal && (subState == SUBSTATE_PvrTimeSearch || subState == SUBSTATE_PvrPlayingSearch || subState == SUBSTATE_PvrRecSearch)) {
            TAP_GenerateEvent(EVT_KEY, RKEY_Exit, RKEY_Exit);
            TAP_GenerateEvent(EVT_KEY, RKEY_PlayList, RKEY_PlayList);
            return dwReturn;
          }
          return param1;
        }
        OSD_ShowDir();
        return dwReturn;
      }

[flechumer]

Offenbar hatte ich da etwas missverstanden. So wie Du es schilderst, ist eine Störung nicht möglich. Mein etwas vorschnelles Urteil tut mir leid. ops:

[Elle4u]

[quote=""flechumer""]Offenbar hatte ich da etwas missverstanden. So wie Du es schilderst, ist eine Störung nicht möglich. Mein etwas vorschnelles Urteil tut mir leid. ops:[/quote]
Kein Problem
Ich lasse mich ja auch gerne eines Besseren belehren

Machst Du denn ein Exit_normal? Denn dann dürfte ja gar kein TAP mehr stören, oder?

[flechumer]

[quote=""Elle4u""]Machst Du denn ein Exit_normal?[/quote]
Was meinst Du mit Exit_normal?

[FireBird]

Nachdem ich Elle schon die Gute-Nacht-Geschichte erzählt habe, antworte ich hier: er meint TAP_ExitNormal und TAP_EnterNormal. Mit ersterem verlässt der Topf den Normal-Modus. In diesem Zustand sollte er keine eigenen OSDs mehr anzeigen. Gleichzeitig können TAPs via TAP_GetState den aktuellen „Zustand“ des Topfes abfragen und sollten nicht selbst aktiv werden, wenn der Topf nicht im Normal-State ist.

[Dixie]

@ Rudolf,
mit der letzten Version kann ich einen provozierten Abbruch mit einer Abbruchmeldung erzeugen.
Wenn ein Abbruch beim Echtschnitt entsteht, blitzt die Meldung nur extrem kurz auf, so das man sie nicht lesen kann.
Gestern hatte ich einen Freeze einfach nach Druck auf >>. Es wurde die Zeitleiste eingeblendet und der Topf hing.

Und kann ich jetzt davon ausgehen, dass Filer, wenn hinter SSP gestartet, nicht die Ursache für die Abbrüche ist?

Vor SSP kann ich Filer ja nicht mehr starten, weil seit der 2.0 die OK-Taste zum Aufruf der Fileliste während einer Wiedergabe genutzt wird.

@ Elle4u,
mein Improbox-Filer-Problem kann nicht damit zu haben? Filer-Post #117

PS: Mit EGAL meinte ich, dass beide Tasten das gleiche Verhalten auslösen.

Dixie

[flechumer]

Um die Frage zu beantworten: SSP macht Tap_ExitNormal vor TAP_Osd_Create und TAP_EnterNormal nach TAP_Osd_Delete. Hilft das irgendwobei weiter?

[FireBird]

[quote=""flechumer""]SSP macht Tap_ExitNormal vor TAP_Osd_Create und TAP_EnterNormal nach TAP_Osd_Delete. Hilft das irgendwobei weiter?[/quote]
Ich habe mich bisher nicht mit SSP beschäftigt. Ist ExitNormal aktiv während Du Dein Tasten-Feuerwerk abspielst?

[flechumer]

Nein, das läuft ohne SSP-Einblendungen ab.

[FireBird]

Was auch gar nichts bringt, da Du sonst keinen Zugriff auf die Schnittfunktionen hast.

[flechumer]

Es geht ja um das Phänomen, was Dixie beschrieben hat, daß nämlich unter bestimmten Umständen OSD-Ausgaben gecancelled werden. Das Dumme ist, daß ich das selbst nicht reproduzieren kann - bei mir bleiben sie für die vorgesehene Zeit stehen. Also gehe ich davon aus, daß irgendeine Art von Fremdeinwirkung vorliegt. Schätze, daß ich darüber eine Weile grübeln muss.

[flechumer]

@Dixie
Ich komme morgen auf Deine Fragen zurück. Tschüss für heute.

[flechumer]

Ich ahne inzwischen, was bei den verkürzten Abbruchmeldungen abläuft: Wenn innerhalb einer Kette von Kommandos ein Kommando einen Timeout hat, gibt SSP die Abbruchmeldung aus. Trifft das Kommando oder ein Folgekommando der gleichen Kette dann doch noch verspätet ein, wird es, da nicht mehr relevant, durchgeleitet und bricht in der Folge die Ausgabe ab.

Die Abhilfe wird etwas auf sich warten lassen, weil ich mitten in einer anderen Änderung stecke, die noch nicht fertig ist.

@Dixie:
Solange das obige Problem noch nicht gelöst ist, kann ich keine Aussagen machen. Ich denke, daß ich bis spätestens morgen eine neue Testversion online stellen kann.

[Elle4u]

Stimmt. Die "OK"-Taste ist ja inzwischen auch aktiv (während einer Wiedergabe)... ops:
Und da SmaSki im normal-Status bleibt könnte dies stören.

Allerdings kommt Filer ja NACH SmaSki und so müsste SmaSki das "OK" ja doch erreichen...

Ich weiß nicht, ob es dafür eine Lösung gibt. Das ein anderes TAP mit Event_Key schneidet ist ja auch außergewöhnlich

Evtl. könnte man es wie beim WSS-Killer machen. Dem kann man ja Kommandos schicken.
Man könnte ein Kommando: "Filer schlafe jetzt mal" schicken und dann wieder "Filer mach weiter"?

Aber dafür müsste man sicher wissen, dass Filer es überhaupt ist...

[flechumer]

Das Problem sollte jetzt beseitigt sein. Ver. 00.04.48 steht zum Download. Änderungen:

1. Timeouts für Kommandos innerhalb einer Kette sind von 1000 auf 1500 ms heraufgesetzt.
2. Es ist dafür gesorgt, daß Abbruchmeldungen mindestens 3 Sek. stehen bleiben bis sie gelöscht werden können.
3. Das Einstellmenü ist dahingehend geändert, daß viele Parameter mit V-, V+ gewählt werden können anstelle von Zahleneingaben (Anregung von Dixie). Das macht die Sache wesentlich übersichtlicher.
4. Die Kurzbeschreibung wurde erweitert.

[flechumer]

Hallo Elle,

leider bin ich gestern nicht mehr dazu gekommen, auf Dein Posting zu antworten. Das will ich jetzt nachholen.

[quote=""Elle4u""]Stimmt. Die "OK"-Taste ist ja inzwischen auch aktiv (während einer Wiedergabe)... Und da SmaSki im normal-Status bleibt könnte dies stören.
Allerdings kommt Filer ja NACH SmaSki und so müsste SmaSki das "OK" ja doch erreichen... [/quote]
Verstehe ich das richtig: Filer interpretiert <ok> bei Wiedergabe und leitet es nicht weiter? Wenn das so ist, ist das ein Problem beim Echtschnitt. Dabei kommt es erst in zweiter Linie darauf an, ob das Kommando SSP erreicht, sondern ob es von der FW ausgeführt wird.

Ich weiß nicht, ob es dafür eine Lösung gibt. Das ein anderes TAP mit Event_Key schneidet ist ja auch außergewöhnlich

Es kommt auch nicht darauf an, ob das Kommando von Hand eingegeben oder per GenerateEvent von einem TAP abgesetzt wird. Das Problem gibt es dann auch beim Schneiden von Hand.

Evtl. könnte man es wie beim WSS-Killer machen. Dem kann man ja Kommandos schicken.
Man könnte ein Kommando: "Filer schlafe jetzt mal" schicken und dann wieder "Filer mach weiter"?

Aber dafür müsste man sicher wissen, dass Filer es überhaupt ist...

Das war mein Ansatz beim Thread "TAP Koordinierung". Wobei es nicht darauf ankam, einem bestimmten TAP etwas mitzuteilen, sondern allen TAPs. Deshalb muss man auch nicht wissen, ob ein bestimmtes TAP existiert oder nicht.

Für's erste wäre es schon hilfreich, wenn jedes TAP auf einfache Weise per Kommando "ruhiggestellt" werden könnte.