Automove 1.8 beta 3, für Firmware ab ca. Version 5.12.05

Happy · #1

Hallo,
Wer beta 2 einsetzt sollte unbedingt auf beta 3 upgraden
Im Moment muß angenommen werden, dass die gefundene Move-Funktion einen Bug hat und in manchen Fällen nicht funktioniert. Es sind dann Abstürze möglich. Die sache ist also mit Vorsicht zu genießen.

hier jetzt die Version, die eine breitere Palette an Modellen unterstützen sollte. Da es in der Version 5.12.05 funktioniert, sollte es auch mit höheren Versionen funktionieren. Evtl sogar mit etwas niedrigeren Versionen.

Unklar ist mir die Application Version des 5200c, auf der Topfield Seite steht:

1. IRD status
(1) System ID : 10446
(2) Loader Version : C1.02
(3) Application Version : TF-NCPCd 1.45
(4) Hardwater version : v1.00
(5) Last Update : Sep 13 2005

Das passt nicht ganz in das Schema 5.xx.xx Weiss jemand, was es damit auf sich hat?
Ansonsten sind hier natürlich Erfolgs- aber auch Mißerfolgsmeldungen erwünscht.

Probieren auf eigene Gefahr

http://tools.hepke.com/automove18b3.zip

Gruß,
Happy

nitram · #2

Super Danke! Werds gleich testen. Schreib dir dann obs klappt.

nitram · #3

FUNKTIONIERT EINWANDFREI! Danke!
Also die T Version kannste abhaken.

Happy · #4

Hier noch der Code zum Moven. Ist leider nicht von mir sondern alleine von bdb

Code: Alles auswählen

bool   (*TAP_Hdd_Move)(char *from_dir, char *to_dir, char *filename);
//----------------- 
enum 
{ 
    oTAP_Hdd_unknown0          = 0x00,  //hdd related, called by debug functions 'rs', 'rc'     -- read sector? 
    oTAP_Hdd_unknown1          = 0x01,  //hdd related, called by debug functions 'ws', 'wc'     -- write sector? 
    oTAP_unknown2              = 0x02,  //writes to eeprom? @ 0xa3ffffe0, 0xa3ffffe1 
    oTAP_Hdd_unknown3          = 0x03,  //ata/dma related, ??? 
    oTAP_Hdd_SetBookmark       = 0x04, 
    oTAP_Hdd_GotoBookmark      = 0x05, 
    oTAP_Hdd_ChangePlaybackPos = 0x06, 
    oTAP_ControlEit            = 0x07, 
    oTAP_SetBk                 = 0x08, 
    oTAP_EPG_UpdateEvent       = 0x09, 
    oTAP_EPG_DeleteEvent       = 0x0a, 
    oTAP_EPG_GetExtInfo        = 0x0b, 
    oTAP_Channel_IsStarted     = 0x0c, 
    oTAP_Vfd_GetStatus         = 0x0d, 
    oTAP_Vfd_Control           = 0x0e, 
    oTAP_Vfd_SendData          = 0x0f, 
    oTAP_Win_SetAvtice         = 0x10, 
    oTAP_Win_SetDrawItemFunc   = 0x11, 
    oTAP_SysOsdControl         = 0x12, 
    oTAP_Hdd_Move              = 0x13, 
    oTAP_Osd_unknown20         = 0x14,  //osd related, ??? 
}; 
extern void * (*TAP_GetSystemProc)( int ); 

bool InitMovePointer()
{

    TAP_Hdd_Move = TAP_GetSystemProc(oTAP_Hdd_Move); 

    if (TAP_Hdd_Move)
    	return TRUE;
    else
    	return FALSE;

}

Funktion 0x14 ist in der Septemberfirmware noch nicht vorhanden jedoch in der 5800 Fw vom Dezember. Insgesamt sind 5 unbekannte Funktionen zu finden.

Gruß,
Happy

Happy · #5

Hallo,
gibts vielleicht noch einen Masterpiece- oder Kabeltester ?

Scheint ansonsten zu funktionieren, die T-Versionen in Australien und Skandinavien funzen auch

Gruß,
Happy

DeJe · #6

Beim Masterpiece mit neuester Firmware funktioniert die Funktion.
Habe zwar nicht Automove getestet aber in meinem TAP klappt es einwandfrei.

okl · #7

Hi Happy,

wollte nur kurz mitteilen, dass Automove prächtig mit 5.12.15 auf meinem 5500er funktioniert. Tolle Arbeit!

Gruss
Olav

Erdnussnase · #8

nitram hat geschrieben:FUNKTIONIERT EINWANDFREI! Danke!
Also die T Version kannste abhaken.

Hallo,

Ich habe gestern, nachdem Firebird die geniale FW mit "Wake me up" Funktionalität gebaut hat auch meine alte FW von März 2005 (t-Modell) in die ewige Bitwüste geschickt.
Dann mußte natürlich auch das Neuste automove her.
Muß aber leider vermelden das es nicht funktioniert hat. Nach starten von automove nimmt der Topf Tastendrücke extrem träge an. Man wartet bis zu 20sec bis was passiert und kurze Zeit später friert er auch ein.
Zweimal mit und ohne automove gegengetestet. Läßt sich eindeutig reproduzieren.
Hat von euch jemand die gepatchte FW schon damit probiert ?

obsolet · #9

Erdnussnase hat geschrieben:Hallo,

Ich habe gestern, nachdem Firebird die geniale FW mit "Wake me up" Funktionalität gebaut hat auch meine alte FW von März 2005 (t-Modell) in die ewige Bitwüste geschickt.
Dann mußte natürlich auch das Neuste automove her.

Wennst ihn ganz lieb anflehst hacked er auch die März FW für dich

Happy · #10

Erdnussnase hat geschrieben:Nach starten von automove nimmt der Topf Tastendrücke extrem träge an. Man wartet bis zu 20sec bis was passiert und kurze Zeit später friert er auch ein.
Zweimal mit und ohne automove gegengetestet. Läßt sich eindeutig reproduzieren.

Autsch. Habe bisher nur eine Meldung zu einem nicht reproduzierbaren Einfrieren bekommen. Sonst nur positiv Meldungen.
Der Move an sich sollte gehen. Evtl ist etwas anderes Schuld.

Hattest du Automove ohne alle anderen TAPs probiert (RAM ist ja zur Zeit Mangelware)?
Standen Dateien zum Moven an? Wurden evtl ein Ordner- oder Historymove vor dem Absturz schon ausgeführt? Zum Testen könnte man einen Testordner und Testaufnahme machen.
Man könnte auch die automove.mov löschen, dann geht aber die History verloren.

Ausser dem Move entspricht die 1.8 genau der 1.7 beta2 und auch seit 1.6 hat sich nichts entscheidendes geändert, was ich als kritisch ansehen würde.

Was heisst Einfrieren? Ich kenne ein Einfrieren des TV-Bildes (meist Absturz der Software) oder ein komplettes Blockieren der FB (z.b. durch Endlosschleife in einem TAP)

Leider erstmal nur Fragen statt Antworten

ops:

Die nächste Version hat eine kleine Änderung: man kann es so einstellen, dass nicht mehr beim Start des TAPs gemovt wird, sondern nur noch auf Kommando aus dem Menü.
Dann könnte man einen Lauf mit Logdatei starten.

Gruß,
Happy

emarzinkowski · #11

ich habe die gepatchte Sept. FW und Automove 1.8 Beta 1 drauf.
Bisher keine Probleme festgestellt.

Happy · #12

ich wollte noch was bemerken:

Nach dem Starten von Automove, macht es 5 Sekunden erstmal gar nichts.
Dann sollte die Plattenaktivität zunehmen (ich höre das leider sehr deutlich

).
Dann wird die Verzeichnisliste für den Ordnermove erstellt. Und verglichen und verschoben. 1 Sekunde Pause
Dann kommt der Historymove jedes Verzeichnis wird einzeln gescannt und evt wird etwas verschoben. Nach jedem Verzeichnis legt sich Automove sogar 1 Sekunde schlafen.
Die FB kann schon etwas träger werden, 20 Sekunden ist natürlich viel zu viel.

Gruß,
Happy

Erdnussnase · #13

War so träge das es indiskutabel ist. War eindeutig länger als sonst.
Ja, habe auch mal nur automove probiert. Egebniss das gleiche.
Es friert das Bild ein.
Ja, es stand eine Datei zum moven an. Die ist auch in der History move vermerkt.

Ich werde mal die *.mov löschen und nochmal testen. Das ist das Beste.
Leider erstmal nur Antworten noch keine Ergebnisse

Happy · #14

Erdnussnase hat geschrieben: Ja, es stand eine Datei zum moven an. Die ist auch in der History move vermerkt.

Und sie wurde auch verschoben ? Welche Art Move war es denn ?
Wie siehst du die Historyliste, wenn der Topf einfriert ? Mit dem Konfigurationstap ?

Gruß,
Happy

Erdnussnase · #15

Happy hat geschrieben:Und sie wurde auch verschoben ? Welche Art Move war es denn ?
Wie siehst du die Historyliste, wenn der Topf einfriert ? Mit dem Konfigurationstap ?

Gruß,
Happy

Es war einer der "Schmeckt nicht, gibt's nicht" Folgen die ich ich seit Monaten aufnehme und Sie per Historymove in den entsprechenden Ordner verschieben lasse.
Ich habe mir die Historymove Liste nicht angesehen, meinte damit nur das die Folgen schon immer so verschoben wurden.

Und nein, die Datei war nachher (nach dem Freeze und Neubooten) nicht verschoben.

ICNW · #16

Erdnussnase hat geschrieben:Hallo,

Ich habe gestern, nachdem Firebird die geniale FW mit "Wake me up" Funktionalität gebaut hat auch meine alte FW von März 2005 (t-Modell) in die ewige Bitwüste geschickt.
Dann mußte natürlich auch das Neuste automove her.
Muß aber leider vermelden das es nicht funktioniert hat. Nach starten von automove nimmt der Topf Tastendrücke extrem träge an. Man wartet bis zu 20sec bis was passiert und kurze Zeit später friert er auch ein.
Zweimal mit und ohne automove gegengetestet. Läßt sich eindeutig reproduzieren.
Hat von euch jemand die gepatchte FW schon damit probiert ?

Hi,

ich hab die gepachte Firmware und AutoMove auf meinem T-Modell. Außer das er nach dem Einschalten ziemlich lange braucht(ich werde die Sekunden mal ermitteln), bis er auf die FB reagiert, gibts keine Probleme (siehe auch die weiteren TAPS in der Sig).

Grüsse
der ingo

Happy · #17

ICNW hat geschrieben: Außer das er nach dem Einschalten ziemlich lange braucht(ich werde die Sekunden mal ermitteln), bis er auf die FB reagiert, gibts keine Probleme (siehe auch die weiteren TAPS in der Sig).

Da wird Automove bestimmt den kleinsten Anteil dran haben.

@Erdnussnase
Du könntest die Datei auch zuerst von Hand mal wegschieben. Dann könnte man sehen, ob Automove dann durch läuft (ohne etwas zu verschieben).
Dann würde es mit dieser Datei zusammenhängen.

Gruß,
Happy

Erdnussnase · #18

Happy hat geschrieben:Da wird Automove bestimmt den kleinsten Anteil dran haben.

@Erdnussnase
Du könntest die Datei auch zuerst von Hand mal wegschieben. Dann könnte man sehen, ob Automove dann durch läuft (ohne etwas zu verschieben).
Dann würde es mit dieser Datei zusammenhängen.

Gruß,
Happy

Hallo Happy,

Zu spät, sie ist weg

Habe Sie gestern abend gelöscht und dann lief autmove wunderbar. Hat auch Dateien verschieben können.
Leider habe ich echt nicht dran gedacht die Datei zu sichern, dann hätte man mal nachsehen können was daran faul war. Schade, geht nun nicht mehr.

Gibts eigentlich irgend einen Weg wie ich von QuickTimer aus Verschiebungsaufträge erstellen kann ?
Ich träume immer noch von der Möglichkeit gleich bei einer Aufnahme festzulegen wo Sie hingeschoben werden soll. Das ganze natürlich so, das ich nicht selbst in automove Dateien rumschreiben muß.
Was würdest Du davon halten eine Datei auomove.cmd einlesen zu können in der ich Verschiebungsaufträge reinschreiben kann ?
Nach dieser könntest Du intervallmäßig suchen und sie nach Überführung in Deine Datenbank löschen. Ähnlich wie JAG, smartEPG oder QT das mit dem Eintragen von Timern über Dateien machen.

macfan · #19

Erdnussnase hat geschrieben:Ich träume immer noch von der Möglichkeit gleich bei einer Aufnahme festzulegen wo Sie hingeschoben werden soll. Das ganze natürlich so, das ich nicht selbst in automove Dateien rumschreiben muß.

Das wird in SmartEPG sicherlich kommen. Du arbeitest mit Jag, da muss wohl mehr geändert werden.

Gruß, Horst

Happy · #20

Erdnussnase hat geschrieben: Zu spät, sie ist weg

Die nächste Folge kommt bestimmt

Erdnussnase hat geschrieben: Habe Sie gestern abend gelöscht und dann lief autmove wunderbar. Hat auch Dateien verschieben können.
Leider habe ich echt nicht dran gedacht die Datei zu sichern, dann hätte man mal nachsehen können was daran faul war. Schade, geht nun nicht mehr.

Auf jeden Fall zeigt das, dass diese Datei die Ursache war. Evtl ist die neue Move-Funktion doch nicht so zuverlässig wie die alte.

Erdnussnase hat geschrieben: Gibts eigentlich irgend einen Weg wie ich von QuickTimer aus Verschiebungsaufträge erstellen kann ?
Ich träume immer noch von der Möglichkeit gleich bei einer Aufnahme festzulegen wo Sie hingeschoben werden soll. Das ganze natürlich so, das ich nicht selbst in automove Dateien rumschreiben muß.
Was würdest Du davon halten eine Datei auomove.cmd einlesen zu können in der ich Verschiebungsaufträge reinschreiben kann ?
Nach dieser könntest Du intervallmäßig suchen und sie nach Überführung in Deine Datenbank löschen. Ähnlich wie JAG, smartEPG oder QT das mit dem Eintragen von Timern über Dateien machen.

Ds hört sich interessant an, da lässt sich betimmt etwas machen.
Spontan würde ich sagen, ich würde dies Kommandos als Vorlagen für einen Historymove in die History eintragen.

Einziges ABER ist im Moment, dass ich ab Sonntag für 2-3 Wochen geschäftlich nach Australien

fliege. Also mit einer schnellen Umsetzung wird das daher nichts.

Gruß,
Happy