Seite 1 von 5
Automove 1.8 beta 3, für Firmware ab ca. Version 5.12.05
Verfasst: Mi 11. Jan 2006, 20:46
von Happy
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
Verfasst: Mi 11. Jan 2006, 21:12
von nitram
Super Danke! Werds gleich testen. Schreib dir dann obs klappt.
Verfasst: Mi 11. Jan 2006, 21:20
von nitram
FUNKTIONIERT EINWANDFREI! Danke!
Also die T Version kannste abhaken.
Verfasst: Mi 11. Jan 2006, 22:14
von Happy
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
Verfasst: Sa 14. Jan 2006, 00:44
von Happy
Hallo,
gibts vielleicht noch einen Masterpiece- oder Kabeltester ?
Scheint ansonsten zu funktionieren, die T-Versionen in Australien und Skandinavien funzen auch
Gruß,
Happy
Verfasst: Sa 14. Jan 2006, 15:21
von DeJe
Beim Masterpiece mit neuester Firmware funktioniert die Funktion.
Habe zwar nicht Automove getestet aber in meinem TAP klappt es einwandfrei.
Verfasst: Mo 16. Jan 2006, 08:47
von okl
Hi Happy,
wollte nur kurz mitteilen, dass Automove prächtig mit 5.12.15 auf meinem 5500er funktioniert. Tolle Arbeit!
Gruss
Olav
Verfasst: Di 17. Jan 2006, 09:46
von Erdnussnase
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 ?
Verfasst: Di 17. Jan 2006, 14:07
von obsolet
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
Verfasst: Di 17. Jan 2006, 14:21
von Happy
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
Verfasst: Di 17. Jan 2006, 14:57
von emarzinkowski
ich habe die gepatchte Sept. FW und Automove 1.8 Beta 1 drauf.
Bisher keine Probleme festgestellt.
Verfasst: Di 17. Jan 2006, 15:06
von Happy
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
Verfasst: Di 17. Jan 2006, 16:00
von Erdnussnase
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
Verfasst: Di 17. Jan 2006, 16:23
von Happy
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
Verfasst: Di 17. Jan 2006, 16:59
von Erdnussnase
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.
Verfasst: Di 17. Jan 2006, 17:50
von ICNW
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
Verfasst: Di 17. Jan 2006, 18:19
von Happy
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
Verfasst: Mi 18. Jan 2006, 12:52
von Erdnussnase
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.
Verfasst: Mi 18. Jan 2006, 15:30
von macfan
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
Verfasst: Mi 18. Jan 2006, 16:01
von Happy
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