Jump to content

Verhalten für Hinzufügedatum bei neuen Inhalten


JCA

Recommended Posts

Hallo,

ich habe die Einstellung "Benutze das Erstelldatum der Datei" ausgewählt (Synology 2413+ mit Emby 4.0.0.2). Es wird aber nie das korrekte Datum genommen. Ich habe größtenteils BD Isos auf dem Server.

 

Woran kann dies liegen?

 

Viele Grüße

 

Jens

Link to comment
Share on other sites

Hallo,

nein, kein besonderes Plugin installiert. Heute Morgen habe ich z.B. eine Bluray ISO hinzugefügt. Laut File Station ist Erstellungsdatum der 19.01.2019 und Änderungsdatum und zuletzt Zugegriffen der 20.01.2019. In der entsprechenden NFO steht: <dateadded>2019-01-18 21:14:19</dateadded>. Davor eine Bluray ISO laut File Station Erstellungsdatum der 19.01.2019 und Änderungsdatum und zuletzt Zugegriffen der 20.01.2019. In der entsprechenden NFO steht: <dateadded>2019-01-12 03:57:35</dateadded>.

 

Werden noch weitere Daten benötigt?

 

Viele Grüße

 

Jens

Link to comment
Share on other sites

Ich denke als nächstes wird Luke nach einem Log vom Hinzufügen fragen :)

Welches Dateisystem nutzt Du auf der betroffenen Festplatte?

Link to comment
Share on other sites

Adminpanel -> Expert -> Logs

Einen Film hinzufügen, bei dem das Problem auftritt und danach die aktuelle embyserver.txt herunterladen und hier hochladen.

Link to comment
Share on other sites

Well, because the creation date of the file is not 18.01.2019 but 19.01.2019. In this example there is no big difference, only one day, but there are many examples, where the difference is more than a month. I don't know, where the date is taken from.

Link to comment
Share on other sites

Eventuell ein Verständnisproblem in Sachen mtime/ctime/crtime?

ext4 unterstützt zwar eine "birth time" für Dateien (crtime), aber keine Ahnung ob die Synologie im Webinterface als "Erstelldatum" die crtime oder die ctime anzeigt.

 

Was gibt denn ein

stat $dateiname

aus?

Link to comment
Share on other sites

Access: (0777/-rwxrwxrwx)  Uid: ( 1024/   admin)   Gid: (  100/   users)

Access: 2019-01-23 11:26:14.553930848 +0100

Modify: 2019-01-23 11:26:14.545930976 +0100

Change: 2019-01-23 11:26:14.545930976 +0100

 Birth: -

 

Das ist von der ISO Datei. Ich habe sie heute noch einmal komplett neu importiert und es wird der 22.01.2019 als Hinzufügedatum angezeigt. In der File Station wird als Erstellungsdatum der 19.01.2019 angezeigt. Oder nutzt der Emby Server nicht die ISO Datei für das Datum?

Link to comment
Share on other sites

Schau mal mit debugfs, ob die bzw. welche crtime bei der Datei gesetzt ist.

Dazu musst Du in folgendes Command noch die inode (hat Dir stat vorhin ausgegeben) und das device, auf dem die Datei liegt, eintragen:

debugfs -R 'stat <$inode>' $device
Link to comment
Share on other sites

So, habe es doch hinbekommen:

 

ctime: 0x5c484146:8228fb80 -- Wed Jan 23 11:26:14 2019

 atime: 0x5c484146:84114180 -- Wed Jan 23 11:26:14 2019

 mtime: 0x5c484146:8228fb80 -- Wed Jan 23 11:26:14 2019

crtime: 0x5c43a330:2c64c77d -- Sat Jan 19 23:22:40 2019

 

Es ist also das richtige Datum in crtime.

Link to comment
Share on other sites

Ja, dann zeigt die Synology wohl die crtime an. Emby nutzt afaik bei der o.g. Option die ctime.

Denke für eine Änderung dieses Verhaltens müsstest Du diesem Feature Request die Bitte nach der crtime hinzufügen und hoffen, dass das irgendwann implementiert wird.

 

Normalerweise ist halt ctime = crtime, wenn an der Datei nichts mehr geändert wird.

Aber keine Ahnung was die Synology ggfs. im Hintergrund treibt..

Edited by hein
Link to comment
Share on other sites

Nee, ich fürchte nicht. Auch ctime stimmt mit dem von Emby ermittelten Datum nicht überein. Sonst wäre ich auch den Weg über den feature Request gegangen. Aber es scheint irgendwo der Wurm drin zu sein und das von Emby ermittelte Datum habe ich noch nirgendwo sonst gesehen.

Link to comment
Share on other sites

Dann bin ich mit meinem Latein auch am Ende..

Eventuell wirklich ein Bug im Zusammenspiel mit der Synology.

Kann das hier leider nicht nachstellen.

 

To summarize for the devs, so they don't have to use google translate :)

JCA is adding a file to the library with the use file creating date option set.

Apparently Emby's dateadded does not conform to any of the unix timestamps (ctime, crtime, mtime, atime) available.

Link to comment
Share on other sites

Which would be what on a *nix system? :)

ctime? Couldn't you use crtime where available?

 

I think JCA's problem might have to do with his disk station / some process doing something to file metadata in the background, thus constantly changing ctime. Hence the disparity between the current ctime of a file and the ctime Emby based it's "date added" on at the time the file was added to the database.

 

@@JCA
Du könntest mal die o.g. Prozedur direkt nacheinander durchlaufen, um zu schauen, ob an der Vermutung etwas dran ist.

Also eine neue Datei auf die Disk Station schieben, mit stat und debugfs direkt die verschiedenen Timestamps einsammeln und dann die Datei in Emby hinzufügen.

Wenn's dann immer noch keine Übereinstimmung gibt, liegt wohl wirklich ein Bug vor.

Link to comment
Share on other sites

My problem is, that emby is not using any comprehensibly date in any case. Emby never uses the correct ctime. I checked before and after files were added to the database. It is always a different date from mtime/ctime/crtime.

 

The problem for me is, that when new films are added to the database, they often don't show on the first page of new films. So Emby should use the correct crtime.

 

In my opinion it's a bug.

Edited by JCA
Link to comment
Share on other sites

If you have nfo files you might be able to use a bulk text editor to edit the files, then after doing that run a library scan in Emby.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...