Bugs/Mark/Meta Revert - Revision history

Deusexmachina: /* Summary */

2012-06-14T19:01:35Z

Summary

← Older revision		Revision as of 19:01, 14 June 2012
Line 3:		Line 3:
	After you read the metadata in, either when you import the track, or get it from sunfly.csv, or edit by hand, when you first open in Producer, it rereads all the metadata from the fly file again, obliterating all your changes, and baking them into the track. So you have to then close Producer, go back to the track in the playlist, re-edit or re-paste from the CSV, run Producer again, and then rebake. It gets REALLY old after awhile! It would be nice if you could push metadata, have it saved, and have Producer actually aware that it has been, so it stops re-reading it from the fly file!		After you read the metadata in, either when you import the track, or get it from sunfly.csv, or edit by hand, when you first open in Producer, it rereads all the metadata from the fly file again, obliterating all your changes, and baking them into the track. So you have to then close Producer, go back to the track in the playlist, re-edit or re-paste from the CSV, run Producer again, and then rebake. It gets REALLY old after awhile! It would be nice if you could push metadata, have it saved, and have Producer actually aware that it has been, so it stops re-reading it from the fly file!

	<span style="color:magenta;">To be more clear, the procedure I would want is to be able to take a block of songs, paste in the metadata from the XML, then push it. From there, edit as needed in Producer.<br>The problem is, first, the Sunfly.csv metadata pulling is not seeming to work ~~latelym~~ and second, as above, if I fix the metadata on a block like this, I lose it all when I first open each track in Producer.		<span style="color:magenta;">To be more clear, the procedure I would want is to be able to take a block of songs, paste in the metadata from the XML, then push it. From there, edit as needed in Producer.<br>The problem is, first, the Sunfly.csv metadata pulling is not seeming to work lately, and second, as above, if I fix the metadata on a block like this, I lose it all when I first open each track in Producer.
	</span>		</span>

Deusexmachina: /* Summary */

2012-06-14T19:01:18Z

Summary

← Older revision		Revision as of 19:01, 14 June 2012
Line 3:		Line 3:
	After you read the metadata in, either when you import the track, or get it from sunfly.csv, or edit by hand, when you first open in Producer, it rereads all the metadata from the fly file again, obliterating all your changes, and baking them into the track. So you have to then close Producer, go back to the track in the playlist, re-edit or re-paste from the CSV, run Producer again, and then rebake. It gets REALLY old after awhile! It would be nice if you could push metadata, have it saved, and have Producer actually aware that it has been, so it stops re-reading it from the fly file!		After you read the metadata in, either when you import the track, or get it from sunfly.csv, or edit by hand, when you first open in Producer, it rereads all the metadata from the fly file again, obliterating all your changes, and baking them into the track. So you have to then close Producer, go back to the track in the playlist, re-edit or re-paste from the CSV, run Producer again, and then rebake. It gets REALLY old after awhile! It would be nice if you could push metadata, have it saved, and have Producer actually aware that it has been, so it stops re-reading it from the fly file!

	<span style="color:magenta;">To be more clear, the procedure I would want is to be able to take a block of songs, paste in the metadata from the XML, then push it. From there, edit as needed in Producer.		<span style="color:magenta;">To be more clear, the procedure I would want is to be able to take a block of songs, paste in the metadata from the XML, then push it. From there, edit as needed in Producer.<br>The problem is, first, the Sunfly.csv metadata pulling is not seeming to work latelym and second, as above, if I fix the metadata on a block like this, I lose it all when I first open each track in Producer.

	The problem is, first, the Sunfly.csv metadata pulling is not seeming to work latelym and second, as above, if I fix the metadata on a block like this, I lose it all when I first open each track in Producer.
	</span>		</span>

Deusexmachina: /* Summary */

2012-06-14T19:00:49Z

Summary

← Older revision		Revision as of 19:00, 14 June 2012
Line 2:		Line 2:
	''Most time consuming since it has to be done ''repeatedly'' on every single track:''		''Most time consuming since it has to be done ''repeatedly'' on every single track:''
	After you read the metadata in, either when you import the track, or get it from sunfly.csv, or edit by hand, when you first open in Producer, it rereads all the metadata from the fly file again, obliterating all your changes, and baking them into the track. So you have to then close Producer, go back to the track in the playlist, re-edit or re-paste from the CSV, run Producer again, and then rebake. It gets REALLY old after awhile! It would be nice if you could push metadata, have it saved, and have Producer actually aware that it has been, so it stops re-reading it from the fly file!		After you read the metadata in, either when you import the track, or get it from sunfly.csv, or edit by hand, when you first open in Producer, it rereads all the metadata from the fly file again, obliterating all your changes, and baking them into the track. So you have to then close Producer, go back to the track in the playlist, re-edit or re-paste from the CSV, run Producer again, and then rebake. It gets REALLY old after awhile! It would be nice if you could push metadata, have it saved, and have Producer actually aware that it has been, so it stops re-reading it from the fly file!

			<span style="color:magenta;">To be more clear, the procedure I would want is to be able to take a block of songs, paste in the metadata from the XML, then push it. From there, edit as needed in Producer.

			The problem is, first, the Sunfly.csv metadata pulling is not seeming to work latelym and second, as above, if I fix the metadata on a block like this, I lose it all when I first open each track in Producer.
			</span>

	==Steps 1==		==Steps 1==

Deusexmachina: /* Steps 1 */

2012-06-14T17:39:54Z

Steps 1

← Older revision		Revision as of 17:39, 14 June 2012
Line 4:		Line 4:

	==Steps 1==		==Steps 1==
	# make sure "auto play when adding single file to library" is turned OFF in prefs <span style="color:magenta;">Pretty sure this is irrelevant in my workflow, as I almost never add single tracks</span>		# make sure "auto play when adding single file to library" is turned OFF in prefs <span style="color:magenta;">Pretty sure this particular step is irrelevant in my workflow, as I almost never add single tracks</span>
	# add a .fly/.mp3 pair (make sure there is no .xml already) <-- will fill in name, composer, publisher, copyright		# add a .fly/.mp3 pair (make sure there is no .xml already) <-- will fill in name, composer, publisher, copyright
	# change the composer to "foo"		# change the composer to "foo"

Deusexmachina: /* Example 1 */

2012-06-14T16:39:03Z

Example 1

← Older revision		Revision as of 16:39, 14 June 2012
Line 28:		Line 28:

	==Example 1==		==Example 1==
	<span style="color:red;">I have added a new share "screenshots" and given you read/write access to it. Inside there is a "bugs" folder. In there, ou can create separate folders for each bug that needs screenshots and/or song files (i know, song files are not screenshots, but whatever). Anyway, once you upload a screenshot pic, you can then put them into the wiki, like below.</span>		<span style="color:red;">I have added a new share "screenshots" and given you read/write access to it. Inside there is a "bugs" folder. In there, you can create separate folders for each bug that needs screenshots and/or song files (i know, song files are not screenshots, but whatever). Anyway, once you upload a screenshot pic, you can then put them into the wiki, like below.</span>

	If you look at SF316-06 - Usher - Scream, you will see that there is a superfluous white space in the Composer field (this is due to a carriage return in the .FLY file). This occurs after I open in Producer. In the second pic, you will see how it was BEFORE I opened in Producer. Notice there is no space (because I edited it out). But as soon as I open in Producer, it rereads the FLY file, and the space is back. I can then edit the field, but if I don't save in Producer, it will reappear.		If you look at SF316-06 - Usher - Scream, you will see that there is a superfluous white space in the Composer field (this is due to a carriage return in the .FLY file). This occurs after I open in Producer. In the second pic, you will see how it was BEFORE I opened in Producer. Notice there is no space (because I edited it out). But as soon as I open in Producer, it rereads the FLY file, and the space is back. I can then edit the field, but if I don't save in Producer, it will reappear.
Line 34:		Line 34:
	http://kjams.com/screenshots/bugs/meta_revert/ex1/Picture_fixed.png<br>		http://kjams.com/screenshots/bugs/meta_revert/ex1/Picture_fixed.png<br>
	http://kjams.com/screenshots/bugs/meta_revert/ex1/Picture_broken.png<br>		http://kjams.com/screenshots/bugs/meta_revert/ex1/Picture_broken.png<br>

	==Example 2==		==Example 2==
	In this example, the first image is the starting state. Not SF316-10 -Far East Movement - Live My Life, specifically the Publisher field. This is the initial state after import:<br>		In this example, the first image is the starting state. Not SF316-10 -Far East Movement - Live My Life, specifically the Publisher field. This is the initial state after import:<br>

Deusexmachina: /* Steps 1 */

2012-06-14T16:38:03Z

Steps 1

← Older revision		Revision as of 16:38, 14 June 2012
Line 4:		Line 4:

	==Steps 1==		==Steps 1==
	# make sure "auto play when adding single file to library" is turned OFF in prefs <span style="color:~~red~~;">Pretty sure this is irrelevant in my workflow, as I almost never add single tracks</span>		# make sure "auto play when adding single file to library" is turned OFF in prefs <span style="color:magenta;">Pretty sure this is irrelevant in my workflow, as I almost never add single tracks</span>
	# add a .fly/.mp3 pair (make sure there is no .xml already) <-- will fill in name, composer, publisher, copyright		# add a .fly/.mp3 pair (make sure there is no .xml already) <-- will fill in name, composer, publisher, copyright
	# change the composer to "foo"		# change the composer to "foo"
	# go to advanced->producer <-- changes composer back to what it was???		# go to advanced->producer <-- changes composer back to what it was???

	<span style="color:~~magenta~~;">when i do the above, i see NO problem at all, doing step 4 does NOT revert composer back to what it was. If you have the same experience (that there is no problem) then please delete this section.</span>		<span style="color:red;">when i do the above, i see NO problem at all, doing step 4 does NOT revert composer back to what it was. If you have the same experience (that there is no problem) then please delete this section.</span>

	I will do this, but I am pretty sure there should be no difference between this and just using a fly file pair I already have, where the XML has been removed, or never made yet.		<span style="color:magenta;">I will do this, but I am pretty sure there should be no difference between this and just using a fly file pair I already have, where the XML has been removed, or never made yet.
	But when I get new tracks, I will do this one at a time, just to clarify/test.		But when I get new tracks, I will do this one at a time, just to clarify/test.</span>

	==Steps 2==		==Steps 2==

Deusexmachina: /* Steps 1 */

2012-06-14T16:37:27Z

Steps 1

← Older revision		Revision as of 16:37, 14 June 2012
Line 9:		Line 9:
	# go to advanced->producer <-- changes composer back to what it was???		# go to advanced->producer <-- changes composer back to what it was???

	<span style="color:~~red~~;">when i do the above, i see NO problem at all, doing step 4 does NOT revert composer back to what it was. If you have the same experience (that there is no problem) then please delete this section.</span>		<span style="color:magenta;">when i do the above, i see NO problem at all, doing step 4 does NOT revert composer back to what it was. If you have the same experience (that there is no problem) then please delete this section.</span>

	I will do this, but I am pretty sure there should be no difference between this and just using a fly file pair I already have, where the XML has been removed, or never made yet.		I will do this, but I am pretty sure there should be no difference between this and just using a fly file pair I already have, where the XML has been removed, or never made yet.

Deusexmachina: /* Steps 1 */

2012-06-14T16:36:58Z

Steps 1

← Older revision		Revision as of 16:36, 14 June 2012
Line 4:		Line 4:

	==Steps 1==		==Steps 1==
	# make sure "auto play when adding single file to library" is turned OFF in prefs		# make sure "auto play when adding single file to library" is turned OFF in prefs <span style="color:red;">Pretty sure this is irrelevant in my workflow, as I almost never add single tracks</span>
	# add a .fly/.mp3 pair (make sure there is no .xml already) <-- will fill in name, composer, publisher, copyright		# add a .fly/.mp3 pair (make sure there is no .xml already) <-- will fill in name, composer, publisher, copyright
	# change the composer to "foo"		# change the composer to "foo"
Line 10:		Line 10:

	<span style="color:red;">when i do the above, i see NO problem at all, doing step 4 does NOT revert composer back to what it was. If you have the same experience (that there is no problem) then please delete this section.</span>		<span style="color:red;">when i do the above, i see NO problem at all, doing step 4 does NOT revert composer back to what it was. If you have the same experience (that there is no problem) then please delete this section.</span>

			I will do this, but I am pretty sure there should be no difference between this and just using a fly file pair I already have, where the XML has been removed, or never made yet.
			But when I get new tracks, I will do this one at a time, just to clarify/test.

	==Steps 2==		==Steps 2==

Dave: Created page with "==Summary== ''Most time consuming since it has to be done ''repeatedly'' on every single track:'' After you read the metadata in, either when you import the track, or get it f..."

2012-06-13T17:56:00Z

Created page with "==Summary== ''Most time consuming since it has to be done ''repeatedly'' on every single track:'' After you read the metadata in, either when you import the track, or get it f..."

New page

==Summary==
''Most time consuming since it has to be done ''repeatedly'' on every single track:''
After you read the metadata in, either when you import the track, or get it from sunfly.csv, or edit by hand, when you first open in Producer, it rereads all the metadata from the fly file again, obliterating all your changes, and baking them into the track. So you have to then close Producer, go back to the track in the playlist, re-edit or re-paste from the CSV, run Producer again, and then rebake. It gets REALLY old after awhile! It would be nice if you could push metadata, have it saved, and have Producer actually aware that it has been, so it stops re-reading it from the fly file!

==Steps 1==
# make sure "auto play when adding single file to library" is turned OFF in prefs
# add a .fly/.mp3 pair (make sure there is no .xml already) <-- will fill in name, composer, publisher, copyright
# change the composer to "foo"
# go to advanced->producer <-- changes composer back to what it was???

when i do the above, i see NO problem at all, doing step 4 does NOT revert composer back to what it was. If you have the same experience (that there is no problem) then please delete this section.

==Steps 2==
#Import as many fly tracks as you want in kJams. 
#Pick a track and edit the metadata in the Browser Window. Composer or Publisher works fine for this example (as in the e-mail I sent). 
#Push metadata (this should lock the edits in place) 
#Open in Producer (This may appear to work at this point). 
#More often than not, your edits will disappear. 
#If things are still fine, clear the cache, quit kJams (just to be sure) and relaunch. 
#Run Producer on the same track 
#The edits are now gone.

What I feel SHOULD be happening, is whatever data is pushed to the XML should supersede any data in the FLY file, regardless. When no such data exists, or the XML does not exist, and there is no data in the media file, THEN the data can come from the FLY file.
This is the only thing that makes logical sense to me. Am I missing something?

==Example 1==
I have added a new share "screenshots" and given you read/write access to it. Inside there is a "bugs" folder. In there, ou can create separate folders for each bug that needs screenshots and/or song files (i know, song files are not screenshots, but whatever). Anyway, once you upload a screenshot pic, you can then put them into the wiki, like below.

If you look at SF316-06 - Usher - Scream, you will see that there is a superfluous white space in the Composer field (this is due to a carriage return in the .FLY file). This occurs after I open in Producer. In the second pic, you will see how it was BEFORE I opened in Producer. Notice there is no space (because I edited it out). But as soon as I open in Producer, it rereads the FLY file, and the space is back. I can then edit the field, but if I don't save in Producer, it will reappear.

http://kjams.com/screenshots/bugs/meta_revert/ex1/Picture_fixed.png 
http://kjams.com/screenshots/bugs/meta_revert/ex1/Picture_broken.png 
==Example 2==
In this example, the first image is the starting state. Not SF316-10 -Far East Movement - Live My Life, specifically the Publisher field. This is the initial state after import: 
http://kjams.com/screenshots/bugs/meta_revert/ex2/1_after_import.png 
I then edit out the white space and "Copyright Control": 
http://kjams.com/screenshots/bugs/meta_revert/ex2/2_edited_copyright.png 
I then push metadata. This should actually save the metadata. But if I clear cache, quit and relaunch (again, just to be sure I wipe everything kJams might be sneakily hiding in memory) and run Producer, voila, the the white space and "Copyright Control" has returned 
http://kjams.com/screenshots/bugs/meta_revert/ex2/3_got_reverted.png