Old 3rd September 2012, 09:02   #1
kzuse
Senior Member
 
kzuse's Avatar
 
Join Date: Oct 2005
Location: (D)
Posts: 484
Send a message via ICQ to kzuse Send a message via Skype™ to kzuse
Bug: Modifying MP4 tag can destroy M4A files

Hi,

I'm not perfectly sure if this is a problem with the Winamp core or with the MP4 input plugin, so I'll open a separate thread.

Lately I edited a bunch of .m4a files (ISO MP4 container with AAC audio track), edited Album names, Artists, etc.

On one file with relatively long comment field I received an error "Cannot write to file" (or similar) and after that the file couldn't be played back any more!

Unfortunately I cannot reproduce as this file is defunct now. It has the same size displayed in Explorer but it just won't play any more.

Is there any bug in the MP4 plugin's tag writer which can destroy MP4 files on rare cases? Maybe it has to do with the long comment field (3 lines full of text, c. 100 characters), maybe not.

Thanks for any investigation!
Best regards,
kzuse
kzuse is offline   Reply With Quote
Old 4th September 2012, 05:23   #2
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 5,804
Send a message via AIM to MrSinatra
have you tried playing the file in other players?

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is offline   Reply With Quote
Old 4th September 2012, 21:19   #3
kzuse
Senior Member
 
kzuse's Avatar
 
Join Date: Oct 2005
Location: (D)
Posts: 484
Send a message via ICQ to kzuse Send a message via Skype™ to kzuse
Yes. I tried with VLC, Windows Media Player, Importing it into Nero, Extracting raw AAC from it with mp4box - all failed.

The file is irreparably destroyed, and I also found a way to reproduce it (it had nothing to do with the length of the comment field):

- Open an .m4a file with AAC audio.
- Double click the scrolling title to bring up the File Info dialog.
- While having it open, clear the playlist via "List Opts" -> "New List"
- Click OK in the File Info dialog.
- Boom! A dialog box appears which states an error but you don't think it's harmful.

- Try to play the file. You won't be able to - it's destroyed.

I would consider this a bug definitely, and not a harmless one, though it's an extremely rare condition under which it occurs, but it can happen.

I'd be glad if you could have a look into that.

Thanks!

Best regards,
kzuse
kzuse is offline   Reply With Quote
Old 5th September 2012, 04:36   #4
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Phoenix, AZ
Posts: 4,842
Hi kzuse,

This is bad news. Hope you can replace your files. If you can remember, what did the error message say? On my system it is not possible to select another WA command outside of the file info dialog while the dialog is still open.

Clicking "OK" in the file info dialog causes WA to try to rewrite the tags in the file being displayed. If this is not what you want to do, it's best to click the "Cancel" button instead of the "OK" button.

For additional protection, I set the 'read only' property flag on all my media files that I don't want written to accidentally. This has saved me many times from inadvertently changing or damaging files between backups.

Winamp Pro v5.666.3516 fully-patched - Quinto Black CT v3.6 skin
Windows 10 Home 64-bit v21H2 desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 5th September 2012, 18:16   #5
kzuse
Senior Member
 
kzuse's Avatar
 
Join Date: Oct 2005
Location: (D)
Posts: 484
Send a message via ICQ to kzuse Send a message via Skype™ to kzuse
Try to use the classic skin. In classic skin, it is possible to select the playlist buttons (List opts -> new list) to clear the list, even while the File info dialog is open!

Regarding my files - no problem, the one file on which it happened first was imported from a CD I still have, and all other files I tested it on afterwards were copies of original files.

Maybe the actual bug is that the File Info dialog is not "modal" in classic skin? Nevertheless it should not happen!

Regarding "OK" and "Cancel": It of course also happens if you actually change something in the File info and intentionally hit OK to write the file! (You can't know before, that, when having cleared the playlist in the meantime, this would result in a damaged file...

Here's a screenshot of the dialog box (I set my Winamp to English language for the screenshot, I normally use German).



Cheers,
kzuse
kzuse is offline   Reply With Quote
Old 5th September 2012, 18:24   #6
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 5,804
Send a message via AIM to MrSinatra
i haven't confirmed the bug yet, but by any chance are you using ANY 3rd party plugins?

what i can't fathom, is why doing what you are doing would damage a file.

why would something in the playlist affect it?

and why would the files metadata be written to/updated if no actual edits were made?

(thats somewhat a different topic i guess, but i do wonder why the app for any file would rewrite the file/tags/metadata if clicking "Ok" when NO changes to the metadata were actually made?)

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is offline   Reply With Quote
Old 5th September 2012, 20:13   #7
kzuse
Senior Member
 
kzuse's Avatar
 
Join Date: Oct 2005
Location: (D)
Posts: 484
Send a message via ICQ to kzuse Send a message via Skype™ to kzuse
First of all:
No, I am not using any 3rd party plugin.

Secondly:
I found an even easier way to reproduce the bug that works with ANY skin and which even makes it somewhat more more likely to happen in "real life" and which is probably the way it happened to me (unintentionally) for the first time.

1. Play an M4A file.
2. Now clear the playlist (let's say, because you want to start off with a clear one). The file still continues playing.
3. Now, open the file info box by double-clicking the scrolling title (let's say, because you suddenly realize that there's a typo in the Song title)
4. In the File info box, correct the typo (or do nothing, as MrSinatra states this might be a separate bug but that's not the point)
5. Click OK.

6. It happens the same as in post #3. The file is rendered unusable.

I suspect that upon clearing the playlist, Winamp internally destroys or drops the metadata structure in memory that belongs to the file currently opened in the File Info box, and when clicking OK in that box, this "empty" structure is being written to the file which corrupts the MP4 header.

The variant of the "steps-to-reproduce" described in this post are much more likely to happen. In fact, the examples given in brackets are the intentions I actually had when it happened to me. I just wanted to start off with a new playlist, but after I cleared it I saw that the currently, still playing, song had a typo in it and I wanted to correct it.

I actually wonder if that did never happen to anyone else?

Another very interesting side fact:
Try to do exactly the same with an MP3 file. There something different will happen: Clicking "OK" will stop playback and bring up a "File open" dialog box! Cancelling this, Winamp will end up Stopped, with no file loaded, and the original MP3 file remain intact and will have the new tag.

I tried to repeat and this time selecting the same MP3 file in the popping-up "File open" dialog, which interestingly ends up in Winamp loading that file and restarting playback at the position it stopped before (upon clicking "OK"). Selecting any other MP3 file will bring up that specific file and play it from that position, but it will not write the tag to that file but always to the originally-loaded file (so with MP3, its not a "harmful" bug). The really bad things seem to happen only with M4A...

I hope these investigations could help you a little bit in trapping the root of that error?

Best regards and many thanks in advance,
kzuse
kzuse is offline   Reply With Quote
Old 6th September 2012, 01:42   #8
PreardyRaxy
Junior Member
 
Join Date: Sep 2012
Posts: 1
Attach Image

I cannt upload image file in new topic. Use only jpeg files.

Can you tell me step by step how to make it?
PreardyRaxy is offline   Reply With Quote
Old 6th September 2012, 04:20   #9
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 5,804
Send a message via AIM to MrSinatra
Quote:
Originally Posted by PreardyRaxy View Post
I cannt upload image file in new topic. Use only jpeg files.

Can you tell me step by step how to make it?
does it have to do with this thread or are you hijacking this thread?

upload to www.mediafire.com and share the link.

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is offline   Reply With Quote
Old 6th September 2012, 04:37   #10
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Phoenix, AZ
Posts: 4,842
Hi kzuse,

You have found a serious bug, even if it only affects 1 file type. Using WA in what maybe an uncommon, but valid, way should never cause file header corruption. I only say the steps you listed maybe uncommon because such a bug should have been widely reported. Hopefully someone officially associated with WA will respond soon.

I noticed quite some time ago (since I started write protecting the files in my collection) that clicking "OK" in the WA file info dialog will lead to WA trying to rewrite the displayed file's header, even if nothing is changed. I can not say if this has always been the case, but it has worked this way for several versions. I think I posted a comment about this last year when asking about another issue and no one replied that it was unusual. Maybe the corruption of the ".m4a" file headers is something new. What version of WA are you using?

Winamp Pro v5.666.3516 fully-patched - Quinto Black CT v3.6 skin
Windows 10 Home 64-bit v21H2 desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 6th September 2012, 07:47   #11
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Phoenix, AZ
Posts: 4,842
Hi kzuse,

As to the files being irreparably destroyed, that is not true if only their headers are damaged. A hex editor can be used to repair the header damage. Of course this is well beyond the skill of most users.

In general, knowledge of what should be in each file's header is needed along with some specifics such as track length. In this case, you could open a damaged file and an undamaged copy in a hex editor and compare the differences to see if only the headers are affected. Or provide copies so that someone else could do the comparison.

What WA could do to avoid a failed update/rewrite attempt from damaging a file is make a copy of the file before an update/rewrite attempt is made. Then the copy could be used to restore things if the attempt generates any kind of error or the copy deleted if the update/rewrite finishes without error. This would require all WA core and official plug-in components to use a common file write routine (which they may already do).

I believe DrO was recently looking at a similar approach for dealing with random unexplained corruption of media library database files.

In the meantime, I assume the corruption does not occur if the update/rewrite is done when the m4a file is not playing. I don't use that format (mostly because there is no easy way to fix a bad header). Any files I acquire of that type, I convert to something else. I had noticed that updating tags of an mp3 while it was playing caused a momentary skip, so I tend to stop playback or wait till play is over before updating the tags of any file type I use with WA. And as you noted, WA is successful updating/rewriting mp3 tags whether the mp3 is playing or not.

Winamp Pro v5.666.3516 fully-patched - Quinto Black CT v3.6 skin
Windows 10 Home 64-bit v21H2 desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 6th September 2012, 07:50   #12
kzuse
Senior Member
 
kzuse's Avatar
 
Join Date: Oct 2005
Location: (D)
Posts: 484
Send a message via ICQ to kzuse Send a message via Skype™ to kzuse
I am using the most current Version, Winamp 5.63.

For the fun of it, I tried to reproduce this on an old machine which still runs Winamp 5.56 (because it's the last version that supports hardware video overlay, which is vital to this machine as it is the only way to play videos with more than 5 frames per second...). And what should I say, it also occurs in Winamp 5.56.

I guess, this bug has been there for a long time but somehow noone ever noticed.
Yes I also hope some official WA developer will respond to it!

Best regards,
kzuse
kzuse is offline   Reply With Quote
Old 6th September 2012, 08:01   #13
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Phoenix, AZ
Posts: 4,842
If the corruption does not occur if the update/rewrite is done when the m4a file is not playing, I guess the WA devs could say that the design did not intend for updates/rewrites of a file while it is playing. Trouble there is the design does nothing to prevent it.

Winamp Pro v5.666.3516 fully-patched - Quinto Black CT v3.6 skin
Windows 10 Home 64-bit v21H2 desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 6th September 2012, 08:22   #14
kzuse
Senior Member
 
kzuse's Avatar
 
Join Date: Oct 2005
Location: (D)
Posts: 484
Send a message via ICQ to kzuse Send a message via Skype™ to kzuse
Quote:
Originally Posted by Aminifu View Post
I guess the WA devs could say that the design did not intend for updates/rewrites of a file while it is playing.
No, it works perfectly also if the file is playing if that file is still in the playlist!

Corruption occurs only if the playlist has been cleared before editing the tag.
kzuse is offline   Reply With Quote
Old 6th September 2012, 10:47   #15
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Phoenix, AZ
Posts: 4,842
Quote:
Originally Posted by kzuse View Post
Corruption occurs only if the playlist has been cleared before editing the tag.
Ok, I guess the bug is triggered by allowing the playlist to be cleared while the file info dialog is open. But that does not explain why mp3s are not also affected. Unless the bug is in the codecs. Then all file types handled by the Nullsoft MP4 Demuxer and/or M4A encoder should also be affected. WA is a complex little bugger, isn't it.

Anyway, those who read this thread now know what not to do until this is fixed. Thanx for sharing.

Winamp Pro v5.666.3516 fully-patched - Quinto Black CT v3.6 skin
Windows 10 Home 64-bit v21H2 desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 6th September 2012, 11:43   #16
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 5,804
Send a message via AIM to MrSinatra
i tend to think that many users don't report bugs for many reasons:

1. they don't think the devs will fix them. i have to say, the devs have been good to me, fixed many issues i reported, but some go unfixed, and thats frustrating.

2. they know something happened, but have no idea how or why. they may even blame themselves.

3. they don't want to bother with a msg board.

4. they simply seek out an alternative. or live with it as is. etc, etc...

as to the OK always rewriting the metadata and perhaps the whole file even when no edits or updates were made, i have always suspected, and frankly assumed this was the case just from how winamp behaves. i wish winamp would not do this, but my guess is that the devs do it this way as a kind of blunt force, so that stubborn things that don't take hold right away can be reapplied. from their POV, its prob easier to just have a blanket rule, esp for stubborn cases (where something isn't seemingly updating at first)

i would wish it to be smarter however.

i don't understand why the "empty structure" of a cleared playlist would be applied to the file via an open file info view box? i suppose the quick fix would be to not allow the playlist buttons to be accessed while the file info view box is open, but that doesn't seem to address the root cause of what is going on under the hood? seems to me wires are getting crossed.

it reminds me of this bug:

http://forums.winamp.com/showthread.php?t=327790

altho that was 3rd party plugin caused, BUT similar in that something seemingly so unrelated could cause it.

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing

Last edited by MrSinatra; 6th September 2012 at 13:18. Reason: typo
MrSinatra is offline   Reply With Quote
Old 6th September 2012, 13:12   #17
kzuse
Senior Member
 
kzuse's Avatar
 
Join Date: Oct 2005
Location: (D)
Posts: 484
Send a message via ICQ to kzuse Send a message via Skype™ to kzuse
Quote:
Originally Posted by Aminifu View Post
Ok, I guess the bug is triggered by allowing the playlist to be cleared while the file info dialog is open.
Quote:
Originally Posted by MrSinatra View Post
i suppose the quick fix would be to not allow the playlist buttons to be accessed while the file info view box is open,
This is only half the truth, as unfortunately this is also happening when FIRST clearing the list (while file is playing) and THEN opening the file Info box via double-click / Alt+3.

As described in post #7.

So a more appropriate fix would rather be to immediately stop playback when the playlist is cleared (and also removing the Song title from the Scroller, displaying only "Winamp 5.xxx".

I.e., unloading the song completely.

But that would also mean a regression in convenience: I very often clear my playlist while having a song still playing, then inserting some other songs and Winamp will play them after the still playing song from the old playist finished.

Do you think it would help if I post a link to this thread in one of the two "Official bug report" threads? I'm just not sure which one...
kzuse is offline   Reply With Quote
Old 6th September 2012, 13:25   #18
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 5,804
Send a message via AIM to MrSinatra
Quote:
Originally Posted by kzuse View Post
This is only half the truth, as unfortunately this is also happening when FIRST clearing the list (while file is playing) and THEN opening the file Info box via double-click / Alt+3.

As described in post #7.
well, you could also prevent that from being allowed while the playlist is in a cleared state. but again, these suggestions of mine don't address the root cause, they merely attempt to prevent the damage.

Quote:
Originally Posted by kzuse View Post
So a more appropriate fix would rather be to immediately stop playback when the playlist is cleared (and also removing the Song title from the Scroller, displaying only "Winamp 5.xxx".

I.e., unloading the song completely.

But that would also mean a regression in convenience: I very often clear my playlist while having a song still playing, then inserting some other songs and Winamp will play them after the still playing song from the old playist finished.
i doubt they would do that, for the reason you cite. better to fix the root cause.

Quote:
Originally Posted by kzuse View Post
Do you think it would help if I post a link to this thread in one of the two "Official bug report" threads? I'm just not sure which one...
i see you did, altho they probably have seen this thread by now. i def consider this a serious bug. ruining a users files should be considered critical.

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is offline   Reply With Quote
Old 6th September 2012, 15:32   #19
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Phoenix, AZ
Posts: 4,842
Quote:
Originally Posted by kzuse View Post
This is only half the truth, as unfortunately this is also happening when FIRST clearing the list (while file is playing) and THEN opening the file Info box via double-click / Alt+3.
Just to be clear, you are still saying the corruption happens when the dialog is closed by clicking "OK'", not when the dialog is opened. Right?

Winamp Pro v5.666.3516 fully-patched - Quinto Black CT v3.6 skin
Windows 10 Home 64-bit v21H2 desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 6th September 2012, 16:10   #20
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Phoenix, AZ
Posts: 4,842
Quote:
Originally Posted by MrSinatra View Post
it reminds me of this bug:

http://forums.winamp.com/showthread.php?t=327790

altho that was 3rd party plugin caused, BUT similar in that something seemingly so unrelated could cause it.
This is starting to get depressing. So many things are left hanging. Once again I thank you, Koopa, and others for your steadfastness in finding and reporting these things.

I've been fortunate to not be affected by a lot of these bugs since I don't try to use the full capabilities of WA. I can only assume by the volume of real bug reports (not requests for new or changed features or issues from those not knowing how things are designed to work) that most users do likewise.

When I first started using WA, so long ago, it was a simple digital music player and I still mostly use it for that. I mostly use other apps for ripping and maintenance (tagging, converting, etc) of music files. I never use WA for viewing video files. I don't want to, but I'm starting to believe that WA is dying under it's own weight. Pushing forward to new platforms without fixing the cracks in its foundation will not save it.

Winamp Pro v5.666.3516 fully-patched - Quinto Black CT v3.6 skin
Windows 10 Home 64-bit v21H2 desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 6th September 2012, 21:23   #21
DrO
 
Join Date: Sep 2003
Posts: 27,873
as i'm having a break from documentation and configuration files, i've had a quick look and it's not a simple fix (though the corruption issue itself is).

the corruption happens due to the file getting mangled in the steps described due to the buffer which held the currently playing filename having been cleared out. so that's a simple two line changes in winamp.exe to resolve it (which would potentially apply to any other formats using the unified alt+3 dialog).

the issue however from fixing that is if the playlist is empty, it now saves the changes to the file correctly without mangling it but due to it doing a stop and restart (as most of the official plug-ins do), the restart isn't working and it throws the open playlist dialog. that behaviour would need to be changed but i don't know how much work that involves (as i've not looked).

-daz
DrO is offline   Reply With Quote
Old 6th September 2012, 23:48   #22
kzuse
Senior Member
 
kzuse's Avatar
 
Join Date: Oct 2005
Location: (D)
Posts: 484
Send a message via ICQ to kzuse Send a message via Skype™ to kzuse
Quote:
Originally Posted by Aminifu
Just to be clear, you are still saying the corruption happens when the dialog is closed by clicking "OK'", not when the dialog is opened. Right?
Yes, exactly.

Quote:
Originally Posted by DrO
the issue however from fixing that is if the playlist is empty, it now saves the changes to the file correctly without mangling it but due to it doing a stop and restart (as most of the official plug-ins do), the restart isn't working and it throws the open playlist dialog. that behaviour would need to be changed but i don't know how much work that involves (as i've not looked).
But that would be a good start for including in the next version. It would throw the same dialog as in the case with MP3 files (irritating the user, but he could just click cancel) - and the tag would be saved fine, the file would remain intact, Winamp would end up in a "Stopped" state (at least if the user clicks "Cancel" in the File Open dialog), so in the end the user would be somewhat irritated but happy.
kzuse is offline   Reply With Quote
Old 7th September 2012, 00:31   #23
DrO
 
Join Date: Sep 2003
Posts: 27,873
Quote:
Originally Posted by kzuse View Post
But that would be a good start for including in the next version. It would throw the same dialog as in the case with MP3 files (irritating the user, but he could just click cancel) - and the tag would be saved fine, the file would remain intact, Winamp would end up in a "Stopped" state (at least if the user clicks "Cancel" in the File Open dialog), so in the end the user would be somewhat irritated but happy.
i've had a bit more of a check through things and i've found a solution for the prior mentioned fix causing the open playlist dialog appearing by adding some additional checks when in the updating mode which so far seems to be working as expected - this required changes in winamp.exe as well as in_mp4.dll (and now in_mp3.dll after seeing your post before i was about to make this reply).

however it initially caused the title to revert to the no-file scenario and then blocked getting the alt+3 dialog to appear again (as it thought there was no file). i've made changes which circumvent that issue so at least with mp3 and mp4 files it will now behave in a more sane manner to how it has been previously (though it will need some more testing but it's such a rare scenario that even if it's still buggy, it'd generally revert to the prior behaviour).

[edit]
and that's flac now updated to do the above mentioned changes. the other plug-ins probably should be updated to cope with it as well but as i've churned through an extra 3hrs on this when i really should have been finishing some other things off, i cannot commit my own time to trying to update plug-ins which are not really setup for the methods being used. so in_mp3, in_mp4 and in_flac will work nicer in the weird scenario this thread covers.

-daz
DrO is offline   Reply With Quote
Old 7th September 2012, 11:44   #24
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Phoenix, AZ
Posts: 4,842
Quote:
Originally Posted by DrO View Post
[edit]
and that's flac now updated to do the above mentioned changes. the other plug-ins probably should be updated to cope with it as well but as i've churned through an extra 3hrs on this when i really should have been finishing some other things off, i cannot commit my own time to trying to update plug-ins which are not really setup for the methods being used. so in_mp3, in_mp4 and in_flac will work nicer in the weird scenario this thread covers.

-daz
What weird scenario Thank you very much DrO. I know you love doing these relatively quick fixes when you are able.

Winamp Pro v5.666.3516 fully-patched - Quinto Black CT v3.6 skin
Windows 10 Home 64-bit v21H2 desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 7th September 2012, 12:25   #25
kzuse
Senior Member
 
kzuse's Avatar
 
Join Date: Oct 2005
Location: (D)
Posts: 484
Send a message via ICQ to kzuse Send a message via Skype™ to kzuse
Yes, thanks a lot, DrO! I'm really looking forward to the next version with those fixes.

Thanks again and have a nice day!
kzuse is offline   Reply With Quote
Old 7th September 2012, 18:49   #26
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 5,804
Send a message via AIM to MrSinatra
awesome DrO. while the first scenario was "weird" i agree, the second scenario actually wasn't far fetched at all.

i am curious if you happen to know or have any thoughts on why winamp writes to the file just by doing an "OK" on view file info, when no edits or changes were made? is there a rationale behind this?

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is offline   Reply With Quote
Old 7th September 2012, 19:10   #27
DrO
 
Join Date: Sep 2003
Posts: 27,873
because that's how the in_mp4 plug-in works. most of the plug-ins only do the actual change on the final write command but in_mp4 seems to be 'funky' and i don't know why (or have the time / means to further investigate other than it's most likely due to how the library it uses works).

generally it doesn't cause an issue but did so in the cleared playlist scenario from the filepath not being seen as valid anymore which caused things to go into a weird state of trying to update something which wasn't the same as when it started to save the tag, hence the partial corruption.

i'm not saying that it's good for it to be writing to the file in the way it does especially if there is no change but i think this is more stemming from the tag writing library ([libmp4v2) and how it works than how Winamp does things (and really editing a playing file in a cleared playlist is a rather weird mode to be doing).

-daz
DrO is offline   Reply With Quote
Old 7th September 2012, 19:21   #28
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 5,804
Send a message via AIM to MrSinatra
i'm sorry DrO, i was unclear... i was asking about a different issue. all the file format plugins seem to do what i am talking about, and its a separate matter from the bug Ksuze reported.

essentially, if a user brings up alt+3 on any file type, yet makes NO changes or edits, if they then click "ok" winamp writes to the file regardless. we all wondered why winamp does so? so i was asking if you happened to know?

i appreciate the further info in your previous post tho, good stuff.

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is offline   Reply With Quote
Old 7th September 2012, 19:35   #29
DrO
 
Join Date: Sep 2003
Posts: 27,873
ok, well that's just how that mode works from the alt+3 dialog (now that i've had a chance to refresh the grey cell). clicking ok sends to the input plug-in the information entered on the alt+3 dialog and it's then down to the input plug-in to determine how to handle that.

however, as it's the same API as used from the library (or anything else which is able to use the API to save data to the tags), when it is called then there is no means to distinguish between an alt+3 usage and other usage of that API. hence it will basically re-write the tag (and do whatever is needed by doing that) even if it doesn't appear to you (the user) that things have changed.

maybe the alt+3 dialog should better track things to not allow the ok button to be enabled until there is a change or just keep it open but ignore calling the write tag API. however, at times it might be better to allow Winamp to re-write the tag even if things didn't seem to change so i'm not keen on altering that handling as there must have been a reason why it was implemented by Will in that way.

-daz
DrO is offline   Reply With Quote
Old 8th September 2012, 12:31   #30
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Phoenix, AZ
Posts: 4,842
Quote:
Originally Posted by DrO View Post

maybe the alt+3 dialog should better track things to not allow the ok button to be enabled until there is a change or just keep it open but ignore calling the write tag API. however, at times it might be better to allow Winamp to re-write the tag even if things didn't seem to change so i'm not keen on altering that handling as there must have been a reason why it was implemented by Will in that way.

-daz
I can understand why you don't want to make substantial changes to the "Alt + 3" dialog. However, when a file's tags are rewritten, the file's modification date is also changed. This leads to all rewritten files being listed in the media library's "Recently Added" view, when all the user did was look at the files' tags in the dialog without changing anything.

If something is changed, that the user is not made aware of in the dialog, then the file modification date should be updated. An alert user would then know that something was changed behind the scenes. If one of my files starts acting strange, one of the first things I do when troubleshooting is check the file's dates.

I suggest changing the label on the "Alt + 3" dialog's "OK" button to "Update". This better states what function is actually performed and gives the user a hint to use the "Cancel" button when no tag changes are made. Using "Cancel" will not change a file in any way and prevent these inadvertent additions to the "Recently Added" listing due to changed modification dates. On the other hand, those users who have noticed this have probably already figured this out.

Winamp Pro v5.666.3516 fully-patched - Quinto Black CT v3.6 skin
Windows 10 Home 64-bit v21H2 desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 8th September 2012, 12:58   #31
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 5,804
Send a message via AIM to MrSinatra
well, don't forget my request to add an "apply" button. so "update" would seem weird with apply as well. besides, ok is the convention.

i would suggest that a beta version be created, and it would have ok, cancel, and apply. ok and apply would always be subdued UNLESS changes/edits were actually "on tap" to be made. the user could then cancel them via cancel, or apply them via apply/ok.

this is the smarter way to design winamp in theory, so lets see if it has any drawbacks (as DrO suggests it might) before releasing it en masse. i would be happy to beta test it.

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is offline   Reply With Quote
Old 8th September 2012, 13:16   #32
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Phoenix, AZ
Posts: 4,842
Quote:
Originally Posted by MrSinatra View Post
well, don't forget my request to add an "apply" button. so "update" would seem weird with apply as well. besides, ok is the convention.

i would suggest that a beta version be created, and it would have ok, cancel, and apply. ok and apply would always be subdued UNLESS changes/edits were actually "on tap" to be made. the user could then cancel them via cancel, or apply them via apply/ok.

this is the smarter way to design winamp in theory, so lets see if it has any drawbacks (as DrO suggests it might) before releasing it en masse. i would be happy to beta test it.
I agree that "Apply" and "Update" would be inappropriate.

If I remember correctly your suggestion would allow the dialog to remain open for subsequent additional changes. I think I agreed with your suggestion in principle, but it would require substantial changes to the current dialog. What I'm suggesting is just a simple label change to alert the user to how the dialog currently works.

A better WA tag editor would of course be welcome, down the line. And DrO should split this discussion off into it's own thread so others can add input.

Winamp Pro v5.666.3516 fully-patched - Quinto Black CT v3.6 skin
Windows 10 Home 64-bit v21H2 desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Old 8th September 2012, 22:44   #33
kzuse
Senior Member
 
kzuse's Avatar
 
Join Date: Oct 2005
Location: (D)
Posts: 484
Send a message via ICQ to kzuse Send a message via Skype™ to kzuse
I think it would just be ok to grey out the OK button unless the user edited anything in any of the text fields. Very easily trackable as just one event handler would have to be added which reacts on the "change value" event of any of the text boxes and then "un-greys" (activates) the OK button.

I could imagine that it would be sort of an easy fix but that's only a guess...

Best regards,
kzuse
kzuse is offline   Reply With Quote
Old 10th September 2012, 14:22   #34
MrSinatra
Forum King
 
MrSinatra's Avatar
 
Join Date: Dec 2004
Location: WKPS, State College
Posts: 5,804
Send a message via AIM to MrSinatra
here is the request:

http://forums.winamp.com/showthread.php?t=334897

i continue to patiently await its implementation. from what i gather, its not diffifcult to do at all, its just a matter of needing the time.

i'm curious if the Ctrl+E method (edit file info) has the same need? if one made no edits, would it still update the file modified date when its "update" button were pressed?

PENN STATE Radio or http://www.LION-Radio.org/
--
BUG #1 = Winamp skips short tracks
Wish #1 = Multiple Column Sorting
Wish #2 = Add TCMP/Compilation editing
MrSinatra is offline   Reply With Quote
Old 10th September 2012, 14:32   #35
DrO
 
Join Date: Sep 2003
Posts: 27,873
Quote:
Originally Posted by MrSinatra View Post
i'm curious if the Ctrl+E method (edit file info) has the same need? if one made no edits, would it still update the file modified date when its "update" button were pressed?
it would alter the modified date. none of the dialogs keep any tracking of what has or hasn't changed. of the two, the libraries ctrl+e one would be simple enough to have it only allow ok if there was a change.

with the alt+3 one it's not as simple as it would need to know what has been changed on it's own pages as well as those which the plug-ins themselves are able to provide and as there is no documented way for doing that, pretty much _all_ plug-ins using that API would need to be updated where possible (from what i remember of how it all works).


then again, i think if the file has been modified then the date should be updated to reflect that even if it's from a tag re-write which should probably have not have happened. but i know there are people who completely freak out about it happening but that is an existing wishlist item from what i remember and would also require _all_ input plug-ins to basically get the current modified date, store it, do the tag changes and then re-write the modified date to what it was making it seem like it hasn't changed. but that then leaves the issue of what is counted as modifying the file if changing the tag is not counted as a modification (which it is).


am not saying that it doesn't make sense to make some of the suggestions which have been made but there are also good reasons to keep it altering the modified time, etc.

-daz
DrO is offline   Reply With Quote
Old 10th September 2012, 15:33   #36
Aminifu
Forum King
 
Aminifu's Avatar
 
Join Date: Aug 2011
Location: Phoenix, AZ
Posts: 4,842
Quote:
Originally Posted by DrO View Post

then again, i think if the file has been modified then the date should be updated to reflect that even if it's from a tag re-write which should probably have not have happened.

-daz
Strictly speaking, a rewrite of the same info is a mod. So an update of the file's mod date is proper. Like you say, the real problem is a "re-write which should probably have not have happened".

Since this has been happening for years with no major uproar from users, I can only assume that those who have a problem with this 'design approach' have learned (as I have) to just use the "Cancel" button after using these dialogs just for looking at tag info. For me, it's just another item on my growing list of possible future changes to keep an eye out for.

Winamp Pro v5.666.3516 fully-patched - Quinto Black CT v3.6 skin
Windows 10 Home 64-bit v21H2 desktop - Logitech Z906 5.1 speaker system
Aminifu is offline   Reply With Quote
Reply
Go Back   Winamp & Shoutcast Forums > Winamp > Winamp Bug Reports

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump