Newest sorting breaks when copying/backup->restore custom songs about beatsabersongbrowser HOT 9 CLOSED

I've been experiencing this issue as well.

Browser checks both the modified and created time of a song folder and uses whichever is newer. After the big song conversation, all folders would end up yielding their modified time (date of the conversion).

Here is what we have:

• The song folder has the creation date you downloaded it. Modified time of the conversion.
• info.json (if it exists) has the correct creation date, modified date of conversion.
• All my info.dat have a creation and modified date of when I converted it.
• The cover art for a song has both the date song was uploaded to beat saver and when you downloaded it. Not all songs have cover art.

There is also sometimes a conflict about what people expect sort by newest to do:

• Sort by the BeatSaver upload date
• Sort by the users download date

What browser does is try to sort by the newer of the two.

It seems like if I grab the dates from the cover file that will always work. If a cover file is missing I can just fall back on the folders creation date (the date you downloaded it originally, pre-conversion).

from beatsabersongbrowser.

5.2.0 is out (https://github.com/halsafar/BeatSaberSongBrowser/releases/tag/5.2.0). Let me know if that fixes it for you.

from beatsabersongbrowser.

Without testing it in game, I think it is still not working as intended because when the file gets copied the creation time gets set to the current system time, only last write is preserved. See the answer at https://superuser.com/questions/146125/how-to-preserve-file-attributes-when-one-copies-files-in-windows

So when the songs have been copied over all creation time timestamps would always be newer than the last write and sorting would be broken again.

This does not happen for the converted songs because in this case the directories are moved and not copied so the creation time timestamp seems to be preserved. (https://github.com/Kylemc1413/SongCore/blob/master/Converter.cs#L172)

Unfortunately I don't think there is a correct way to handle the scenario of a reinstall when all songs are copied from some backup, because during the initial backup process (copying your songs folder away) the timestamps are already wrong. And there is no way to restore the original timestamps.

I mean you could always use the last write timestamp but this does not correspond to the download date of the song and the semantics of "newest" sort would be different.
To handle this correctly a "restore/copy detection" is needed, e.g. if the timestamps of all song dirs are within 1 hour they were most likely copied together and not newly downloaded. I don't know if something like this is reliable enough.

from beatsabersongbrowser.

Check out the covert art for any song that got converted. The cover art retained all original dates on my NTFS partition. So the original logic of using the newest time between created/modified still works if you examine the cover art file. If the covert art does not exist it will fall back to the folders Created time which again on my NTFS partition was retained during the song conversion. The folders modified time is the time it was converted.

Give it a test. Works great on my end. Out of a few thousand songs only 1 of mine was missing a covert art.

from beatsabersongbrowser.

A song I picked at random that was converted when we all switched to SongCore.

from beatsabersongbrowser.

We can always convert Newest to using the upload date on BeatSaver. However I think most people expect it to sort by the date they downloaded a song. Which means we have to rely on the file timestamps which are easily corrupted by Windows (NTFS) drives (lack of obvious copy with preserve timestamp equivalent). I am also not sure exactly what we can do in the a case a user modified their own timestamps.

We could record the timestamps the first time we see a song somewhere.

from beatsabersongbrowser.

Here is a small powershell script for you to test around, it shows exactly the behavior I have described above and can be used as a playground for investigating Windows timestamps after copy and move operations. Just source the attached file in powershell (for security pls have a look at it before doing so).

Usage:

PS I:\test> get-help Start-TimestampTest

NAME
    Start-TimestampTest

SYNTAX
    Start-TimestampTest [-TestPath] <string> [[-Cleanup] <bool>] [[-UseMove] <bool>] [[-SongCount] <int>]
    [<CommonParameters>]

What it does is it creates a fake song directory with SongCount number of songdirs in it in the TestPath and then it either copys it or moves it to a destination directory. After everything is done it cleans up the created directory.
It tries to compare the objects and shows the different timestamps (this is a little odd when using move as it shows differences but the values are the same)

timestamps.zip

from beatsabersongbrowser.

I was taken by surprise when this happened too. Feels like there could be two sortings (newest song, recently favorited) Since we only have one playlist I want to see songs at the top that I added recently as I added them so I could practice them - doesn't matter to me about download date, but I can understand why some people would want that.

from beatsabersongbrowser.

Is there a way maybe to support symbolic links?
Without the copy hassle...

from beatsabersongbrowser.