Hallo
Die vu+ Ultimo 4k ist von der Idee und den Möglichkeiten super Toll, aber pflege intensiv wie ein behindertes Kind, wenn man das so sagen darf.
dev/hdd = Samsung SSD 860 EVO 1 TByte
dev/hdd1 = ext USB 3 FANTEC Qb-35US3R Raid 5 4x4TB = 12 TB
Jeden Tag braucht es seine Reboots.
Wenn man keine Aufnahmen verpassen will, muß sie mit in den Urlaub ....
Gestern hab ich endlich rausgefunden, was die Ursache für den täglich hängenden Database Update Job ist.
1. Dei Database ist die vtidb.db (bei mir in /hdd (/dev/hdd)) war auch nicht so einfach bei dieser Fehlermeldung)
2. der Fehler tritt jeden tag nachdem die Box in Standby geschaltet wird, auf. (Inventarisierung der Filmdatenbank)
ok.
Die Datenbank selber ist nicht die Ursache. konnte sie problemlos öffnen und bearbeiten.
--> Fehler beim Job der die DB füllt.
Den Job konnte ich bis jetzt immer noch nicht finden, aber nachdem ich die db gelöscht hab und mir die letzten Einträge vor dem Hänger im Verzeichnis angeschaut hab war die Ursache klar.
Grund war *.ts mit 0 byte Größe
Gibt es übrigens ein Shell Script, welches mir solche Fehler automatisch bereinigt (immerhin 15 *.ts Dateien gefunden mit Größe 0), und es sind ja auch noch reste von *.eit, *.ts.ap, *.ts.cuts, *ts.meta und *.ts.sc Dateien die ja alle zusammen gehören und die vermehrt ohne die Filmdatei *.ts die Festplatten vermüllen
übrigens falls jemand mit der vtidb was anfangen möchte hab ich ne View erstellt die zumindest das Datum anständig anzeigt. keine Ahnung warum so was nicht als Standard in der DB ist kostet ja keine menge speicher
Alles anzeigen
Gruß
Dracul
Die vu+ Ultimo 4k ist von der Idee und den Möglichkeiten super Toll, aber pflege intensiv wie ein behindertes Kind, wenn man das so sagen darf.
dev/hdd = Samsung SSD 860 EVO 1 TByte
dev/hdd1 = ext USB 3 FANTEC Qb-35US3R Raid 5 4x4TB = 12 TB
Jeden Tag braucht es seine Reboots.
Wenn man keine Aufnahmen verpassen will, muß sie mit in den Urlaub ....
Gestern hab ich endlich rausgefunden, was die Ursache für den täglich hängenden Database Update Job ist.
1. Dei Database ist die vtidb.db (bei mir in /hdd (/dev/hdd)) war auch nicht so einfach bei dieser Fehlermeldung)
2. der Fehler tritt jeden tag nachdem die Box in Standby geschaltet wird, auf. (Inventarisierung der Filmdatenbank)
ok.
Die Datenbank selber ist nicht die Ursache. konnte sie problemlos öffnen und bearbeiten.
--> Fehler beim Job der die DB füllt.
Den Job konnte ich bis jetzt immer noch nicht finden, aber nachdem ich die db gelöscht hab und mir die letzten Einträge vor dem Hänger im Verzeichnis angeschaut hab war die Ursache klar.
Grund war *.ts mit 0 byte Größe
Gibt es übrigens ein Shell Script, welches mir solche Fehler automatisch bereinigt (immerhin 15 *.ts Dateien gefunden mit Größe 0), und es sind ja auch noch reste von *.eit, *.ts.ap, *.ts.cuts, *ts.meta und *.ts.sc Dateien die ja alle zusammen gehören und die vermehrt ohne die Filmdatei *.ts die Festplatten vermüllen
übrigens falls jemand mit der vtidb was anfangen möchte hab ich ne View erstellt die zumindest das Datum anständig anzeigt. keine Ahnung warum so was nicht als Standard in der DB ist kostet ja keine menge speicher
SQL-Abfrage
- CREATE VIEW "HIE_ohne_Sort" AS
- select
- IsRecording Aufn,
- IsTrash gel,
- strftime('%d.%m.%Y %H:%M', datetime(TrashTime, 'unixepoch')) TrashTime,
- strftime('%d.%m.%Y %H:%M', datetime(begin, 'unixepoch')) begin_hie,
- strftime('%H:%M', datetime(duration, 'unixepoch')) dauer,
- strftime('%H:%M:%S', datetime(lastpos, 'unixepoch')) lastpos,
- progress '%',
- fsize/1024/1024/1024 GB,
- fsize/1024/1024 MByte,
- Episode,
- --duration/3600 duration_h, duration/60 duration_min,
- fp_4u0fl04t16id Dateiname,
- shortDesc,
- extDesc,
- path,
- title,
- lpos_4u0fl04t16id lPos,
- fname,
- autotags,
- tags,
- VideoResoltuion,
- ref,
- AspectRatio,
- VideoFormat,
- IsDir,
- ContentType,
- Season,
- CollectionID,
- AudioFormat,
- AudioChannels,
- TvdbID,
- genre,
- TmdbID
- from moviedb_v0001
Dracul
das einzige auf dass man sich verlassen kann ist dass die Box hängt wenn man sie dringend braucht.