MyBB Internal: One or more warnings occurred. Please contact your administrator for assistance.
MyBB Internal: One or more warnings occurred. Please contact your administrator for assistance.
MyBB Internal: One or more warnings occurred. Please contact your administrator for assistance.
MyBB Internal: One or more warnings occurred. Please contact your administrator for assistance.
Nightingale Forums - I do not want Nightingale to modify all files - which it does

Nightingale Forums

Full Version: I do not want Nightingale to modify all files - which it does
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hello! Thanks for your great work on this project. Finally updated my Mac experience from PowerPC to Intel with Snow Leopard and was excited this meant I could run Nightingale. Was going to test out and also run under my Linux installs if it went well. It looks promising, but regardless of how I set preferences, the program changes modification date of each and every OGG or FLAC file I play ( I haven't tested MP3 or AAC) so I have uninstalled. EDIT: Tested under Linux Mint. Same thing happens. Tested AAC. Same thing happens. And Nightingale doesn't just modify file first time it plays; it modifies file each and every time it plays. Tested MP3 - does not seem to happen! Also, regardless of file type, this does not happen if I play file from local EXT4 Linux drive; it only happens when I play from my external HFS+ drives. Haven't tested FAT32 or NTFS or anything else, as I primarily installed for Mac & Linux use. Uninstalled from Linux Mint as well. (Well, tried to. I ran uninstall in Software Manager and it's still there, but now it just won't launch)

I don't want Nightingale to automatically alter my files for two reasons -
A) I've got metadata set as I want and have no idea what, if anything, this program I haven't even tested yet is modifying. (What is being modified, and why?)
B) I have an enormous music library and backups of it and do not want to needlessly have to back up every single file I've played when I run my backup software.

So, unfortunately, this means I can't use Nightingale. Has anyone else seen this issue, and perhaps discovered a way around it?
(01-08-2014, 04:19 AM)libraryeye Wrote: [ -> ]I don't want Nightingale to automatically alter my files

I'm not aware of features automatically altering your files. However, Nightingale updates play count and skip count tags internally, that might cause the file to get accessed by tagging code. It should not change anything, though.

What is changed exactly? Does the change only affect file attributes (probably the last modified date), or is the actual content of the file changed (run md5sum or another hashing tool on the file before and after the playback, if the value changes that means that the file's content is changed)? If the actual content of the file is changed, can you download a CC-licensed piece of music somewhere (for example jamendo), play it and upload the changed file and post the original download link? We can then investigate what part of the file changed and might find the issue.
(01-08-2014, 11:31 AM)rsjtdrjgfuzkfg Wrote: [ -> ]
(01-08-2014, 04:19 AM)libraryeye Wrote: [ -> ]I don't want Nightingale to automatically alter my files

I'm not aware of features automatically altering your files. However, Nightingale updates play count and skip count tags internally, that might cause the file to get accessed by tagging code. It should not change anything, though.

What is changed exactly? Does the change only affect file attributes (probably the last modified date), or is the actual content of the file changed (run md5sum or another hashing tool on the file before and after the playback, if the value changes that means that the file's content is changed)? If the actual content of the file is changed, can you download a CC-licensed piece of music somewhere (for example jamendo), play it and upload the changed file and post the original download link? We can then investigate what part of the file changed and might find the issue.

Hi rsjtdrjgfuzkfg,

thanks for reply. I can look into running a hashing tool when I have a minute. For now, far as I can tell, all that's changing is the last modified date. This is still problematic though as it will necessitate a new backup of a file every time I play a file, since I use Carbon Copy Cloner and other backup software that backups files anytime there's a new modification date.
(01-08-2014, 12:36 PM)libraryeye Wrote: [ -> ]This is still problematic though as it will necessitate a new backup of a file every time I play a file, since I use Carbon Copy Cloner and other backup software that backups files anytime there's a new modification date.

I didn't intended to say that only changing the change date is not an issue; I'm asking for these details to nail the bug down, so that we can then have a look on the parts of the code that may cause it in detail.
yes, i understand. I was just trying to clarify my concern. thanks for looking into this. let me first say, songbird did the same thing so i wouldn't use that either.

Jamendo, and the first couple other CC-licensed music sites I found, ironically provide music in the non-free MP3 format! And, this Nightingale issue doesn't seem to affect MP3, just AAC, OGG, FLAC and maybe more. So I went to:
http://www.oggwatch.com/listings/oggvorbis/music

which linked me over to Kahvi Collective, where I downloaded this EP from "OGG" link:
http://www.kahvi.org/releases.php?release_number=335

Ok, this behavior is maddeningly inconsistent...

I'm doing this in Mac OSX Snow Leopard, though I have same issues with Linux Mint install. I had already deleted Nightingale app. So I deleted
Users/"username"/Library/Preferences/com.getnightingale.songbird.plist
&
Users/"username"/Library/Application Support/Nightingale

so I could start fresh.

Now, it wasn't causing the issue! So I went & checked prefs in app. I noticed it did not default to same prefs as when I first installed. This time
"Artwork> Store artwork within each file's metadata"
which was on last time I installed, but which I had disabled in attempt to avoid this issue, was not checked. In course of testing this I have reinstalled the app (after deleting plist and app support folder) four times. Each time, different artwork & fetcher priorities prefs were enabled upon install! Here's what I discovered: If at any point after install, both "Store artwork within each file's metadata" & "Auto-fetch Album Artwork" are checked, the issue occurs. Even if either or both are then unchecked; once the undesired (by me, at least) behavior starts, it continues even if I disable the suspect prefs. Oddly, with FLAC & AAC it didn't matter which sequence I had first enabled these prefs in, where with OGG it did. Nonetheless, the only way to stop this behavior once it begins is to -
• delete Nightingale app
• delete Users/"username"/Library/Preferences/com.getnightingale.songbird.plist
&
• delete Users/"username"/Library/Application Support/Nightingale
& make sure at least "Store artwork within each file's metadata" is unchecked before ever playing a single track. That's the behavior I've seen so far.

So, for this test you can download the original files of the OGG formatted EP from above. I checked "Store artwork within each file's metadata" & "Auto-fetch Album Artwork" and issue affected the first played track: "Gamma." Then I unchecked these options and played "Beta." The issue persisted. I have made a zip archive of that "Beta" file (the original album from Kahvi site downloads in a zip) and posted it here:
https://web-dc2.spideroak.com/browse/sha...ubliq_Lee/

thanks again! I look forward to hearing your results.

(01-09-2014, 03:40 AM)rsjtdrjgfuzkfg Wrote: [ -> ]
(01-08-2014, 12:36 PM)libraryeye Wrote: [ -> ]This is still problematic though as it will necessitate a new backup of a file every time I play a file, since I use Carbon Copy Cloner and other backup software that backups files anytime there's a new modification date.

I didn't intended to say that only changing the change date is not an issue; I'm asking for these details to nail the bug down, so that we can then have a look on the parts of the code that may cause it in detail.
(01-09-2014, 08:05 AM)libraryeye Wrote: [ -> ]I look forward to hearing your results.

Hm. So it definitly is something related to metadata. Following observations:

1. The metadata's field descriptors are transformed from lower- to upper case.
2. The metadata field was too long in the original file. For MP3, that is possible to make metadata changes more easy (as addresses of the music streams stay the same), I'd assume ogg has a similar feature. The empty space was removed by nightingale.
3. Tags are sorted alphabetically (instead of seemingly random as they were before)
4. The actual tag values are left unchanged

This seems to me like Nightingale wrote the tags on the file, without actally changing anything. This would have the output we see, as taglib would then re-create the whole metadata section of the file. This may happen due to the cover search feature. I did not fully understand the different cases of your reproduction, yet. However I don't have a mac and thus can't reproduce it anyways.

Is the file changed again if you play it another time? If no, you could play all files one time, then do a backup and live with it until we found the issue.

If you are able to find a case always causing the issue, I can try to reproduce it on windows as well. If I can reproduce it, there is a chance that I can trace it down in code. If not, we'd need to have a look at all parts of the code triggering a metadata update, and assert the cases actually try to change something. Maybe the code tries to write the cover art? As this is not fully supported on all file types, this may trigger a rewrite of the tags without any visible output. To assert that's not the case, disable cover art detection / writing completely before playing anything. If that fixes the issue, then it's not a bug but a missing feature (of the actual cover art writing).
In my experience, when this issue occurs it occurs every time I play a file - not just the first time. So that means every time I play a file, it will trigger a new backup.
Yes, if I disable the art features (it does not detect embedded nor local art anyway, at least not the AAC & OGG & MP3 files I've tried so far) then the files are not affected. Except... I have to disable these features before I ever use app. If I have those options enabled then if if I disable them the app seems to modify files even after I have disabled those preferences. I need to fully uninstall app & remove associated files (plist & app support folder) then reinstall and disable the art prefs before ever playing a single file, that's what I've seen so far.
(01-09-2014, 11:39 AM)libraryeye Wrote: [ -> ]I need to fully uninstall app & remove associated files (plist & app support folder) then reinstall and disable the art prefs before ever playing a single file, that's what I've seen so far.

Ok, thanks. From this thread, the following issues are now tracked:

Issue #243: Feature request for disabling useless tag writing, for the general issue of tags being written without actual changes.

Issue #242: Bug report on not being able to disable cover art writing after the installation. Please ensure the STR (Steps to reproduce, some kind of tutorial on how to reproduce the bug) in the issue is correct and that all important aspects are listed.

If you wish another aspect of the discussion to get tracked, let me know or fill an issue by yourself.