Zukunft von Automove/Filer ?

[nitram]

Hallo Topfieldgemeinde ich wollte mal eine Diskussion eröffnen die mir schon lange unter den Nägeln brennt.

Da es seit den aktuellen Firmwares (für alle Geräte) ja diese Move-Funktion nicht mehr gibt ist die Zukunft von so tollen Programmen wie Automove und bald auch Filer (sowie es dort eine Move Funktion gibt) mehr als unklar.

Bringt es denn jetzt noch etwas so viel Herzblut und Arbeit in ein Programm zu stecken was mit der nächsten Firmware sich schon komplett erledigt haben könnte? Ich weiß, dass die aktuelle Firmware für den 5000PVR anscheinend mangelhaft ist doch für mich als PVR-T User ist diese Firmware dringend notwendig gewesen.

Nun stellte mich die Firmware leider vor einen neuen Konflikt. Die Frage hieß entweder auf die neuen Versionen von Improbox zu verzichten oder auf die tollen Funktionen von Automove. Ich sage euch diesen Konflikt wünscht man nichtmal seinem ärgsten Feind. (na gut George Bush hätte es sich verdient)
Schweren Herzens entschloss ich mich dann für Improbox, da zukünftige Taps wahrscheinlich eh alle auf der "neuen" Api (ja für PVR-T User ist die noch neu) aufbauen werden.

Was wäre wenn die nächsten Firmware so toll wäre das alle wechseln möchten/müssen , wenn z.B. ein dritter Tuner Software mäßig bereitgestellt werden kann oder die Festplatte durch ein geniales Verfahren verdreifacht wird ohne das man Geschwindigkeitseinbußen hat
Oder der Oberhamme : ALLE Fehler wären beseitigt!
Ihr könnt euch selbst die Frage stellen welche der 3 Varianten am wahrscheinlichsten ist

Um nun zum Punkt zu kommen, was treibt euch dazu diese veraltete Move-Funktion weiter zu nutzen obwohl sie doch anscheinend schnee von Gestern ist. Ich weiß es gibt zur Zeit nix was diese Funktion ersetzen könnte, doch was gibt euch die Energie trotzdem mit dieser Funktion weiter zuarbeiten?

Wisst ihr vielleicht von etwas wovon ich noch nichts weiß ? Vielleicht könnte man ja die Koreaner davon überzeugen, bei der nächsten Firmware einen ähnlichen Befehl wieder zu integrieren.

Die PVR-T User stehen jetzt schon vor Problemen, die ihr erst in ein paar Monaten haben werdet also schaut mich an und blickt in eure Zukunft

[ibbi]

Wisst ihr vielleicht von etwas wovon ich noch nichts weiß ? Vielleicht könnte man ja die Koreaner davon überzeugen, bei der nächsten Firmware einen ähnlichen Befehl wieder zu integrieren.

Man müsste sie bitten , einen entsprechenden Befehl in die offizielle API aufzunehmen!

[steve]

Ich weiß es gibt zur Zeit nix was diese Funktion ersetzen könnte,

Ich frage mich gerade in diesem Zusammenhang, wie denn die Originalfunktion des Movebefehls funktioniert. Gemeint ist die gelbe Taste im Originalfilemenü.
Ich bin zwar nur Laie, aber vielleicht geht ja darüber was..... :

[ibbi]

Ich frage mich gerade in diesem Zusammenhang, wie denn die Originalfunktion des Movebefehls funktioniert. Gemeint ist die gelbe Taste im Originalfilemenü.

Die Firmware des Topfs wird sicherlich nicht auf die API angewiesen sein. Die Funktion(en) gibt es natürlich, sie müssen eben nur "veröffentlicht" werden.

[Erdnussnase]

Ich frage mich gerade in diesem Zusammenhang, wie denn die Originalfunktion des Movebefehls funktioniert. Gemeint ist die gelbe Taste im Originalfilemenü.
Ich bin zwar nur Laie, aber vielleicht geht ja darüber was.....

Ich habe mich auch schon immer gefragt, wieso die move funktion nicht einfach über SImulation von Tastendrücken gemacht wird.
Gut, gibt's immer Geflacker auf dem Bildschirm. Das könnte man aber mittels speziellen Timers in die frühen Morgenstunden bzw. Nachstunden erledigen, wenn keiner vor dem Topf sitzt.
Ist nicht ganz so komfortabel, weil es nur einmal am Tag gehen würde, aber trotzdem besser als gar nichts.

[ibbi]

Ich habe mich auch schon immer gefragt, wieso die move funktion nicht einfach über SImulation von Tastendrücken gemacht wird.

Und schon ist die Idee eines programmierbaren Makro-Recorder-TAPs geboren ...

[nitram]

schön das hört sich doch schonmal nach einer Möglichkeit an

Vielleicht könnten ja mal Happy und Elle4u sagen ob sowas möglich wäre

das wäre zwar sicher noch keine Lösung für den Filer aber für Automove könnte man sich doch sowas vorstellen

[eber]

Wenn man den Move per gelber Taste simuliert geschieht das praktisch im Blindflug - und damit problematisch, da die Sortierung unterschiedlich sein kann.
Das wird zum einen sehr aufwendig und zum anderen trotzdem wacklig.

Ich hatte ja schon mal eine andere Idee geschildert, von der ich aber nicht sicher bin ob sie funktioniert.

Man öffnet eine beliebiges File mit TAP_HDD_Fopen, bekommt dabei einen Pointer auf ein TYPE_File.
In dieser Struktur (TYPE_File) setzt man nun das Feld Startcluster auf den Festplattensektor den man lesen bzw. schreiben möchte.
Mit TAP_Hdd_Fwrite/Fread schreibt/liest man nun aus der geöffneten Datei die ersten 512 Byte. Wenn meine Idee klappt holt sich der Topf die Daten dann aus dem Cluster den man in Startcluster eingetragen hat.
Fazit:
Falls das klappt könnte man auf diese Weise jeden belieben Cluster der Festplatte lesen/schreiben.
Wenn man nun noch das Filesystem des Topfs kennt (und das ist ja soweit bekannt) könnte man auf diese Weise eine eigene Move-Funktion basteln.
Es geht ja letztlich nur darum, in zwei Verzeichnissen einen Änderung vorzunehmen (Eintrag aus Sourceverzeichnis entfernen und Eintrag in Targetverzeichnis einfügen).
Allerdings fehlt mir die Zeit (und der Mut ) so etwas selbst in Angriff zu nehmen. Aber vielleicht findet sich ja ein Fanatiker...

Grüße

Eber

[DeJe]

Die Idee oder so ähnlich hatte ich auch und habe deshalb die Tools installiert.
Leider ist die Doku alles andere als brauchbar. Außer der dürftigen Beschreibung der Parameter steht nix drin.

Also ich würde mich gern mal an die Sache ransetzen. Klar, das würde recht lange dauern. Blockweise die Daten kopieren und dann die Originaldatei löschen. Aber immerhin könnte es so klappen und man wäre nicht von der Firmware abhängig. Zur Not auch ein die Holzhammermethode:

Src öffnen, Block lesen, Src schließen, Dir wechseln, Dst öffnen, Block schreiben, Dst schließen, zurückwechseln Src öffnen, ... usw.

Ich hatte erst gehofft die "TAP_Hdd_Rename" könnte man mißbrauchen. Aber leider Pustekuchen.
Vielleicht kann ja mal einer der Topfield-Mitarbeiter hier einen kurzen Kommentar abgeben. IMHO muß eine Move-Funktion elementarer Bestandteil der API sein.

[DeJe]

Die Idee oder so ähnlich hatte ich auch und habe deshalb die Tools installiert.
Leider ist die Doku alles andere als brauchbar. Außer der dürftigen Beschreibung der Parameter steht nix drin.

Also ich würde mich gern mal an die Sache ransetzen. Klar, das würde recht lange dauern. Blockweise die Daten kopieren und dann die Originaldatei löschen. Aber immerhin könnte es so klappen und man wäre nicht von der Firmware abhängig. Zur Not auch ein die Holzhammermethode:

Src öffnen, Block lesen, Src schließen, Dir wechseln, Dst öffnen, Block schreiben, Dst schließen, zurückwechseln Src öffnen, ... usw.

Ich hatte erst gehofft die "TAP_Hdd_Rename" könnte man mißbrauchen. Aber leider Pustekuchen.
Vielleicht kann ja mal einer der Topfield-Mitarbeiter hier einen kurzen Kommentar abgeben. IMHO muß eine Move-Funktion elementarer Bestandteil der API sein.

Von Tasten zu simulieren halte ich gar nichts. Da kann viel zu viel schiefgehen.

[eber]

@DeJe:
Jetzt hast Du mich glaube ich mißverstanden. Blockweises kopieren geht auch ohne Verrenkungen ganz normal per Hdd_Fread/Fwrite.
Allerdings ist das so furchtbar langsam das es wahrscheinlich eine ganze Nacht für einen Film dauert.
Meine Idee besteht darin die interne Verwaltungsstruktur (TYPE_File - ist auch in irgendeiner *.h Datei dokumentiert) einer geöffneten Datei so zu manipulieren, das die Firmware statt auf die Cluster der Datei auf Cluster der Directories zugreift. Und wenn man die Directories entsprechend manipuliert (das ist ein "FAT24"-System und daher relativ simpel aufgebaut) dann könnte man selbst die Datei "verschieben" ohne das man die Datei selbst lesen muß. Also rasend schnell...
Der Topf merkt sich beim Öffnen einer Datei deren Startcluster innerhalb von TYPE_File. Und der Aufbau dieser Struktur ist wie gesagt in einem *.h-File definiert. Meine Idee ist nun dort (im RAM) den Startcluster zu manipulieren. Wenn meine Idee klappt könnte man auf diese Weise jeden beliebigen Plattensektor lesen/schreiben. Und wenn erstmal das funktioniert ist es nur noch eine Fleißarbeit eine eigene Move-Routine zu stricken.
Das ist zwar auch nicht die feine Art aber solange Topfield das Filesystem nicht ändert wäre es firmwareunabhängig...
Grüße

Eber

[Happy]

Hallo,
habe noch nie ernsthaft daran gedacht den Move mit Tastendrücken zu emulieren. Das wäre wohl wirklich ein Glücksspiel. Das werde ich wohl nicht versuchen.
Eigentlich hatte Topfield (also der alte Kontakt von damals) eine Move-Funktion in der Api zugesagt. "Man hätte übersehen, dass die fehlt". Leider hatte die API, die folgte noch keinen Move-Befehl. Ich hoffe aber,dass die nächste API, so sich da noch etwas tut,eine entsprechende Funktion enthalten wird.
Ebers Idee ist auch etwas abenteuerlich. Wahrscheinlich findet DeadBeef vorher einen Ersatz für die Movefunktion
Ich warte zur Zeit ab, was sich tut. Also neue API oder neue Firmware.

Gruß,
Happy

[nitram]

erstmal danke für die anregende Diskussion.
also bleibt uns nur hoffen ?

[DeJe]

@Eber,
Habe wie gesagt mit der Topf-Programmierung gerade erst angefangen. Aber Filesysteme (insbesondere FAT12/16/32 was auch immer) sind mir nicht fremd. Ich gehe nach deinem Post mal davon aus das Ihr das schon getestet habt. Ich hatte angenommen das es doch schneller geht mit direktem Kopieren, bin halt doch andere Hardware gewohnt.

Allerdings erscheint mir Deine Methode ebenso abenteuerlich. Wenn der Topf Infos cached kann das ganz böse enden.
Ich hätte kein Problem entsprechende Routinen zu schreiben das Directory einer FAT direkt zu manipulieren. Ob das allerdings mit dem Topf funkt...ich bin da skeptisch.
Nicht zu vergessen, ob sich der Aufwand letztlich lohnt.

Wie auch immer. Irgendwie muß eine Move-Funktion her!
Ich will Filer, und ich will diesen mit einer Move-Funktion! Leider ist er ohne Move für mich eher nicht brauchtbar und ich muß mich mit dem Standard-Filer begnügen. Da funktioniert es ja problemlos.
Also ihr Topf-Macher, gebt den TAPs-Hackern die Move-Funktion...und zwar (das Wort mit den 5 Buchstaben) Dalli.

[Elle4u]

Um nun zum Punkt zu kommen, was treibt euch dazu diese veraltete Move-Funktion weiter zu nutzen obwohl sie doch anscheinend schnee von Gestern ist. Ich weiß es gibt zur Zeit nix was diese Funktion ersetzen könnte, doch was gibt euch die Energie trotzdem mit dieser Funktion weiter zuarbeiten?

Deshalb scheue ich mich im Moment ja davor, diese überhaupt zu implementieren Es gibt noch so viele offene Baustellen bei Filer und diese habe ich hinten angestellt (zumindest nach der alten Methode).
Ich habe mir auch schon Gedanken über einen Move gemacht. Mit Tasten-Simulation auf keinen Fall. Ich hatte auch schonmal darüber nachgedacht, daß Filesystem zu manipulieren. Es muß ja möglich sein, die Directories umzubiegen.
Wenn ich aber sehe welche Unterschiede es zwischen den verschiedenen Topf-Typen es gibt... Allein der Datei-Header weicht schon von Typ zu Typ ab

Evtl. kann uns Firebird da auch helfen... : :

[eber]

@Eber,
Habe wie gesagt mit der Topf-Programmierung gerade erst angefangen. Aber Filesysteme (insbesondere FAT12/16/32 was auch immer) sind mir nicht fremd. Ich gehe nach deinem Post mal davon aus das Ihr das schon getestet habt. Ich hatte angenommen das es doch schneller geht mit direktem Kopieren, bin halt doch andere Hardware gewohnt.

Ich habe den Verdacht, das man per API die Festplatte nur im PIO-Mode ansprechen kann. Da der MIPS-Prozessor sehr lahm ist (aus heutiger Sicht : - was man ja auch am lahmen USB-Port erkennt) dauern dadurch Übertragungen zur Festplatte sehr lange. Bei der Aufzeichnung/Wiedergabe läuft es dann vermutlich per DMA, so das der Prozessor kaum zu tun hat.
Kopieren und anschließendes Löschen ist daher per TAP nicht mit vernünftiger Performance realisierbar.

Allerdings erscheint mir Deine Methode ebenso abenteuerlich. Wenn der Topf Infos cached kann das ganz böse enden.

die gute (bzw. eigentlich schlechte) Nachricht. Das Topf-Filesystem ist vollkommen ungecached. Macht ja auch bei Aufzeichnung und Wiedergabe von Filmen kaum Sinn.

Ich hätte kein Problem entsprechende Routinen zu schreiben das Directory einer FAT direkt zu manipulieren. Ob das allerdings mit dem Topf funkt...ich bin da skeptisch.

ich bin auch sehr skeptisch. Wäre trotzdem interessant zu wissen, ob der Trick mit der StartCluster-Verbiegung funktioniert. Man muß ja am Anfang nur Lesen. Schreiben wäre sicher zunächst riskant....

Nicht zu vergessen, ob sich der Aufwand letztlich lohnt.

Der wäre allerdings heftig - selbst wenn es prinzipiell klappt

Wie auch immer. Irgendwie muß eine Move-Funktion her!

Genau!

Ich will Filer, und ich will diesen mit einer Move-Funktion! Leider ist er ohne Move für mich eher nicht brauchtbar und ich muß mich mit dem Standard-Filer begnügen. Da funktioniert es ja problemlos.
Also ihr Topf-Macher, gebt den TAPs-Hackern die Move-Funktion...und zwar (das Wort mit den 5 Buchstaben) Dalli.

[/QUOTE]
Auf koreanisch hat das sicher ein paar Buchstaben mehr :
Nachdem dieses Board aber eh schon von Topfield betrieben wird wäre es doch nur normal, wenn es einen Thread (meinetwegen in einer geschlossenen Benutzergruppe) gäbe, auf den die Topfield-Entwickler aus Korea Zugriff hätten. Wir müßten dort dann eben auf Englisch diskutieren. Wenn wir erst einmal eine direkte Connection zu einem der Programmierer haben wäre sicherlich vieles einfacher als wenn da irgendein Verwaltungsfuzzi dazwischenhängt. Denn so schwer kann es wirklich (für Topfield) nicht sein, die Move-Funktion die ja also solche in der Firmware enthalten sein muß per API verfügbar zu machen. Und das wäre natürlich die vernünftigste Lösung.

Grüße

Eber

[FireBird]

Wenn Du den Teufel schon an die Wand malst

Also die 5000er Dateisysteme sind für alle Typen gleich. Einen Verzeichniseintrag zu löschen und in einem anderen Cluster anzulegen ist auch kein Problem. Der Topf merkt sich aber zusätzlich die verbrauchten Cluster aller Files des aktuellen Verzeichnisses und dessen Unterverzeichnisse. Man muss also schon mehrere Parameter manipulieren.

Ich werde Ebers Startcluster-Idee einmal versuchen, sonst erübrigt sich obiges sowieso.

Am besten wäre natürlich eine API-Funktion. Keine Ahnung ob im Fahrwasser dieses Boards auch die Kommunikation mit Korea wieder besser wird.

[eber]

@Firebird:
Im Prinzip wäre es wahrscheinlich noch einfacher, per normalem API im Zielordner zunächst mal eine leere Datei gleichen Namens wie die zu verschiebende anzulegen.
Dann müßte man nur noch die beiden Startcluster-Werte der beiden Dir-Einträge im Quell und Zielordner vertauschen und anschließend dann die Dummy-Datei im Source-Ordner wieder per API löschen.
Allerdings müßte man dann noch die Anzahl der verbrauchten Cluster in beiden Verzeichnissen korrigieren.
Ich schätze die Wahrscheinlichkeit das der Trick mit dem Startcluster funktioniert auf 50%.
Blöd wäre es nur, wenn der Rückgabepointer von TAP_Hdd_Fopen nur auf eine Kopie der internen Verwaltungsstruktur zeigt. Da aber das Filesystem eher auf die schnelle programmiert wurde (mein Eindruck) besteht Hoffnung.

Grüße

Eber

[Elle4u]

Wäre super, wenn wir da zusammen eine Lösung hinbekommen würden.
Stelle mich auch gerne als VersuchsTopf zur Verfügung

[FireBird]

Ich schätze die Wahrscheinlichkeit das der Trick mit dem Startcluster funktioniert auf 50%.

Ich sage nur