Zukunft von Automove/Filer ?

[nitram]

da der Filer doch das gesamte Filesystem ersetzt wäre es da nicht "einfach" möglich, das einem nur der Filer anzeigt, dass alle Dateien schön geordnet in ihren Verzeichnissen liegen ? Mir reicht ja schon die Illusion!
Sozusagen der Filer legt eine Datenbank an die ihm sagt wo welche Datei liegt. Diese Verzeichnisse legt er dann auch nur imaginär im Tap selbst an.

Das einzige was dann noch problematisch werden könnte ist, wenn man dann mal wirklich per USB eine Datei finden will. Aber ich denke damit könnte ich leben.

[ibbi]

da der Filer doch das gesamte Filesystem ersetzt wäre es da nicht "einfach" möglich, das einem nur der Filer anzeigt, dass alle Dateien schön geordnet in ihren Verzeichnissen liegen ? Mir reicht ja schon die Illusion!
Sozusagen der Filer legt eine Datenbank an die ihm sagt wo welche Datei liegt. Diese Verzeichnisse legt er dann auch nur imaginär im Tap selbst an.

Interessante Idee.

Man könnte die Information vielleicht auch im Dateinamen selbst ablegen, also in der Art Serien_Lost_<echter Name>. Allerdings weiß ich nicht, wie lang ein Dateiname beim Topf sein darf.

Die Zurverfügungstellung der offiziellen Funktion, die es ja in der Firmware geben muss, wäre allerdings der sicherste Weg. Mir ist sowieso schleierhaft, wieso die Topfield-Programmierer nicht (enger) mit den TAP-Programmierern zusammenarbeiten.

[eber]

Etwas ähnliches habe ich bei Smartepg mal angefangen. Dort kann man jeder aufgezeichneten Sendung eine "Kategorie" zuordnen (Krimi,Spielfilm etc).
Die Fileliste in Smartepg zeigt auf Wunsch dann nur Filme einer bestimmten Kategorie. Im Prinzip sind diese Kategorien auch eine Art "virtuelle" Ordner.

Die Lösung hätte den Vorteil das wir das mit offiziellen Mitteln machen könnten.
Allerdings sollte ein gemeinsamer Standard her, damit alle Taps die "virtuellen" Ordner verwalten können.
Der Filename ist meines Erachtens nicht so ideal (Gefahr beim Umbenennen, Längenbegrenzung etc.)
Da es praktisch nur für rec-Files relevant ist könnte man die Info in deren Header unterbringen. Es gibt dort einen ziemlich großen Bereich zur Aufnahme der erweiterten Beschreibung (die sowieso fast nie stimmt).
Dort könnte man dann entweder direkt einen "virtuellen" Ordnerpfad hinterlegen oder zumindest eine eindeutige Ordner-Nr, mit der man dann in einer zentralen Liste den virtuellen Ordner bestimmen kann.
Der Header hätte auch folgende Vorteile:
- bleibt auch beim Schneiden der Datei vorhanden
- manuelles Verschieben oder Umbenennen des rec-Files sind gefahrlos möglich

Grüße

Eber

[emarzinkowski]

Etwas ähnliches habe ich bei Smartepg mal angefangen. Dort kann man jeder aufgezeichneten Sendung eine "Kategorie" zuordnen (Krimi,Spielfilm etc).

geht das nicht nur für TiVo Aufnahmen?
wie kann ich eine manuell per EPG programmierte Aufnahme dem zuordnen.
Und wie sieht es dann mit Sofortaufnahmen aus, die z.B. über Improbox gestartet werden?

[nitram]

Also erstmal finde ich es toll das man hier so schön konstruktiv diskutieren kann

Zum Thema :

Man bräuchte natürlich ein einheitliches System. Sowas ähnliches wie es das jetzt auch schon zwischen dem Filer und Improbox bezüglich des Papierkorbes gibt.

Kleine Teile von Kommunikation zwischen den Taps gibt es ja jetzt schon und das ist auch gut so

geht das nicht nur für TiVo Aufnahmen?
wie kann ich eine manuell per EPG programmierte Aufnahme dem zuordnen.
Und wie sieht es dann mit Sofortaufnahmen aus, die z.B. über Improbox gestartet werden?

Bei manuell programmierten Sachen per EPG müsste entweder das EPG mitspielen (Jag oder Eber sind hier gefragt) oder man kann Automove so umschreiben, dass es die gleiche Funktion wie jetzt ausübt aber virtuell.
Und man müsste dann wenn es per Automove nicht verschoben wird (spez. Filme oder ähnliches) das ganze wiederum per Filer virtuell verschieben können.

Das wäre sicherlich ein Mammutprojekt, da nach und nach immer mehr Taps mit dem gleichen System arbeiten und auf die gleiche Datenbank zugreifen müssten.

[eber]

Sobald Smartepg das "fremde" rec-File entdeckt hat, kann man dieses nachträglich einer Kategorie zuordnen.

Habe aber während des Mittagessen noch mal nachgedacht.
Eine zentrale Liste aller rec-Files (im DataFiles-Ordner) wäre doch die bessere Lösung.
Die Datei (Vorschlag: "DIRINFO.DAT") würde ungefähr so aussehen:

1324434:2005-12-13 14:00=\DataFiles\Krimis
1364434:2005-12-13 12:00=\DataFiles\Kids
2123233:2005-11-14 13:45=\DataFiles\Nachrichten
usw.
die erste Zahl wäre der Startcluster des rec-Files. Dieser Startcluster verändert sich beim Umbenennen/Verschieben von Dateien nicht (nur evt. beim Schneiden)
Gefolgt vom Datum/Uhrzeit des rec-Files (hat technische Gründe)
anschließend der Pfad des "virtuellen" Ordners.

Vorteile:
- Taps könnten eine Fileliste viel schneller aufbauen als bisher. Die API-Funktionen sind ja langsam aber eine einzelne Datei (DIRINFO.DAT) zu lesen geht noch relativ schnell. Elle4u kennt ja auch die bescheidene Performance von TAP_Hdd_FindNext()
- wir müssen nicht im Header rumpfuschen - also vollkommen saubere Programmierung
- eigentlich gibt es diese Liste schon fast. Gerti müßte eigentlich in Improbox schon eine ähnliche Liste programmiert haben nur mit dem Unterschied, das statt einem virtuellen Ordnerpfad die letzte Abspielposition gespeichert wird.
Wenn man beide Liste zusammenfaßt hätten wir eine schöne Lösung....
und ein Großteil des Codes wäre auch schon fertig!

Grüße

Eber

[emarzinkowski]

das hört sich doch prima an.
Wenn Elle4u das in filer einbauen könnte, wäre das Problem mit dem Move doch erledigt.
Ich hoffe er liest hier mit?

[DeJe]

Ui, das klingt richtig gut!

Und wenn es entsprechend gut gekapselt ist wäre es ein Leichtes auf die offizielle API umzustellen.

Die Frage ist nur, wie hält man diese Datenbank aktuell? Insbesondere wenn neue Dateien dazukommen bzw. gelöscht werden (durch die Standardprogramme bzw. über USB)?

[eber]

Moven wäre dann ein Klacks
Wenn wir uns auf einen Standard einigen könnten würde ich das auch in Smartepg unterstützen. Aus meinen bisherigen Kategorien würde ich dann einfach virtuelle Ordner machen.

Grüße

Eber

Ui, das klingt richtig gut!

Und wenn es entsprechend gut gekapselt ist wäre es ein Leichtes auf die offizielle API umzustellen.

Die Frage ist nur, wie hält man diese Datenbank aktuell? Insbesondere wenn neue Dateien dazukommen bzw. gelöscht werden (durch die Standardprogramme bzw. über USB)?

Es müßte eine Library erstellt werden, die jeder Entwickler in sein TAP einbinden kann. Dort würde es dann auch eine Funktion "UpdateDirInfoDat" geben, die einmal den DataFiles-Ordner nach neuen Files durchsucht und diese in DIRINFO.DAT einträgt (zunächst mir ihrem realen Ordnerpfad) und natürlich auch Einträge aus der Liste entfernt die real nicht mehr vorhanden sind. Evt. notiert man noch in DIRINFO.DAT wann der letzte Update stattgefunden hat - fertig ist die Laube...

Grüße

Eber

[Erdnussnase]

Interessantes Thema.

Wenn Ihr beide Listen (virtueller Ordner) und letze Abspielposition) zusammenfassen wollt, solltet Ihr euch beeilen. Gerti bastelt gerade an dem Code rum. Ob er davon begeistert ist weiß ich aber nicht.

Ich fände es allerdings nicht schlecht eine Möglichkeit zu haben schon zum Zeitpunktder Timererstellung einen "Zielordner" angeben zu können. Das gibt die jetzige Idee ja leider noch nicht her.

[bornemann]

Also das klingt echt gut.
Und wenns funktioniert und alle an einem Strang ziehen würden, wäre das ja schon fast genial.

Kompliment Eber!

[eber]

Interessantes Thema.

Wenn Ihr beide Listen (virtueller Ordner) und letze Abspielposition) zusammenfassen wollt, solltet Ihr euch beeilen. Gerti bastelt gerade an dem Code rum. Ob er davon begeistert ist weiß ich aber nicht.

Da werde ich mal nachfragen...

Ich fände es allerdings nicht schlecht eine Möglichkeit zu haben schon zum Zeitpunktder Timererstellung einen "Zielordner" angeben zu können. Das gibt die jetzige Idee ja leider noch nicht her.

Vielleicht folgender Ansatz:
Man schreibt (auf Wunsch) einen Dummy-Eintrag vor der Aufname in DIRINFO.DAT.
Aufbau:
Startcluster=0
Datum/Uhrzeit=Startzeit des Timers
Pfad=Pfad+"/Filename des Timers."

also etwas so:

0000000:2005-12-13 20:15=\DataFiles\Krimis\Tatort- der Mörder bla.rec

Wird nun von der Funktion UpdateDirInfoDat ein neues rec-File gefunden das zu einem solchem Eintrag (mit Startcluster=0) paßt dann wird dieser entsprechend angepaßt.

4711081:2005-12-13 20:15=\DataFiles\Krimis

Ist das Datum/Uhrzeit in einem Dummy-Eintrag bereits mehr als 15 min in der Vergangenheit und es wurde kein passendes rec-File gefunden, dann kann man den Dummy-Eintrag auch automatisch wieder entfernen. Auch das könnte UpdateDirInfoDat() automatisch durchführen.

Grüße

Eber

[eber]

Ach ja - einen speziellen Standardpfad sollten wir auch noch vorsehen :

2123233:2005-11-14 13:45=\DataFiles\Papierkorb

Hierhin würden Rec-Files "verschoben" die der Benutzer "löschen" möchte.
Physikalisch gelöscht wird dann aber nur, wenn der freie Plattenplatz einen bestimmten einstellbaren Wert unterschreitet (die älteste dann zuerst!)
Das Löschen könnte UpdateDirInfoDat() ebenfalls nebenher verwalten...

Grüße

Eber

[DeJe]

Na dann. Auf gehts...

Wir sollten dazu vielleicht einen eigenen Thread erstellen und vorerst mal das API der Library und Struktur der Datenbank klären. Ich wäre gern bereit mitzumachen.

[eber]

Ich habe Gerti mal angeschrieben. Wir sollten auf jeden Fall noch abwarten was er dazu meint.
Wichtig wäre das die meistbenutzten Taps das unterstützen - ich bin dabei und würde auch den Code sponsern mit der man mit Hilfe des Startcluster die dazugehörige Datei im Filesystem findet (egal wohin sie verschoben wurde und auch wenn sie einen neuen Namen bekommen hat).

Zu überlegen wäre auch noch, welche sonstigen Infos noch mit in DIRINFO.DAT reinsollen. Elle4u verwaltet ja glaube ich noch die Anzahl der Minuten die man von einem Rec-File schon gesehen hat.
Evt. wäre auch noch ein Verfallsdatum sinnvoll.


Grüße

Eber

[Erdnussnase]

0000000:2005-12-13 20:15=\DataFiles\Krimis\Tatort- der Mörder bla.rec

Ja, gute Idee. Zu beachten wäre allerdings das sich der Dateiname bei den Aufnahme ändern kann, indem eine Nummer hintenangestellt wird.

Ich schlage auch vor, das selbst wenn DIRINFO.DAT eine Textdatei ist, die Länge einer Zeile festgelegt wird, dann halt mit Leerzeichen auffüllen. Ansonsten müßte man beim löschen bzw. ändern eines Eintrages u.U. das komplette File neu erstellen. Oder man macht die Datei gleich binär. Mir wären aber beide Varianten recht.

[eber]

Zum schnelleren Anzeige einer Fileliste wäre es doch besser man würde in DIRINFO.DAT nicht zur den Pfad sondern auch den Filenamen speichern.
(Sonst müßte man diesen zunächst mit Hilfe des Startclusters bestimmen was zwar funktioniert aber doch länger dauert).
Vielleicht sollte man noch die serviceNum und den serviceType mit auflisten. Damit könnte man dann die neuen rec-Files unabhängig von ihrem Dateinamen einem Dummy-Eintrag zuordnen (ServiceNum+Typ+Startzeit sind ja eindeutig)

Also:

47110815:T001:2005-12-13 20:15=\DataFiles\Krimis\Tatort- der Mörder bla.rec
T001 wäre dann TV-Kanal 1 (beginnend bei 1 oder 0?)

zusätzlich noch eine Konvention mit der das ganze auch nachträglich erweiterbar wird

47110815:T001:2005-12-13 20:15=\DataFiles\Krimis\Tatort- der Mörder bla.rec|Improbox:ReplayPos=45:59|SmartEPG:KeepTime=2005-12-30|KidProtect :P IN=0815|Filer:MinutesAllreadyViewed=045

Damit könnte jeder TAP-Entwickler seine eigene Infos mit reinpacken. Und wenn das nicht interessiert schneidet man einfach den Filenamen ab | ab

Allerdings ist die Frage von Erdnussnase offen: Wie speichert man das effizient.

Grüße

Eber

[DeJe]

Gibt es beim Topf eigentlich die Möglichkeit einer Inter-TAP-Kommunikation?

Dann müßte nicht jedes TAP die gesamte Lib einkompilieren und man könnte sie als TSR-TAP laufen lassen. Das würde auch die Synchronisation (Zugriffe auf die Datenbank) stark vereinfachen.

[eber]

Da arbeiten u.a. Erdnussnase und ich auch schon dran

Wir haben nur mehr Ideen als Zeit

[Gerti]

Hi!

Dann melde ich mich mal zu Wort...
Die Datei an der ich arbeite basiert auf einer Idee von Erdnussnase und sieht einen Header vor, in dem die Anzahl der verwendeten Einträge steht und die nur beim Start geladen wird und dann im Speicher weiter bearbeitet und auf der Festplatte jedoch stets aktualisiert wird.
In dieser Datei werden jedoch auch aktuelle Positionen von noch laufenden Aufnahmen gespeichert.
Wichtig ist für mich auf Fälle, dass diese Datei stets die neuesten Einträge am Anfang hat (also das zuletzt gesehene File) an erster Stelle steht.

Wenn wir die Listen kombinieren wollen (was vielleicht durchaus Sinn machen würde), dann müsste man von der Header-Idee wohl wieder abrücken und jeder müsste die Datei bei Bedarf laden und nach einer Änderung wieder schreiben.

Ich habe im Prinzip nichts dagegen, dass wir so eine Datei gemeinsam nutzen, sofern meine Ansprüche berücksichtigt werden würden.

Gruß,
Gerti