Bug 1382 – Exporting makes a clean project dirty even if project metadata was not changed.

••• Introduction •••
••• Keywords •••

Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla

Bug 1382 - Exporting makes a clean project dirty even if project metadata was not changed.


Summary:	Exporting makes a clean project dirty even if project metadata was not changed.

Status:	RESOLVED QUICKFIXED

Product:	Audacity
Classification:	Unclassified
Component:	Formats
Version:	2.1.3
Hardware:	Per OS Other

Importance:	P3 Repeatable
Assigned To:	Paul L

URL:
Keywords:	test_single_OS

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2016-04-19 11:55 UTC by Gale Andrews
Modified:	2018-08-20 11:51 UTC (History)
CC List:	7 users (show)

See Also:
Steps To Reproduce:	1 Launch Audacity. Generate Tone, Save Project. 2 Export as any format, OK on Edit Metadata without changing the metadata. 3 File > Close. You are asked if you want to save changes, despite the project, including the metadata, has not changed.
Release Note:	GROUP: Exports * '''Exporting from a "clean" saved project makes the project "dirty", thus warning about unsaved changes if closed''' even if the metadata tags stored in the project were not modified by the export.
First Git SHA:
Group:	---
Workaround:
Closed:	2018-08-20 00:00:00

Flags:	gale: Test‑OK‑Lin+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Gale Andrews 2016-04-19 11:55:08 UTC

The same happens (correctly, though it won't seem like that to some users) if Metadata Editor is turned off in Import / Export Preferences. 

I think this is P3/P4 borderline but does have potential for confusing users "Uh? what changed, will I be saving something I don't intend"?    

So, Paul, is it practical to check if the metadata has really changed or not before setting the project dirty and adding the exported tags action to the Undo Stack?

Comment 1 Paul L 2016-04-19 13:18:38 UTC

Yes, it should be easy enough to fix.  I caused this in my fix for bug 1327 and bug 1337.  I will take this.

Comment 2 Paul L 2016-04-19 18:16:23 UTC

Fixed at https://github.com/audacity/audacity/commit/a0290c09d253cc34b3841e7d463b0abbc1c7115f

Comment 3 Gale Andrews 2016-05-24 12:41:29 UTC

(In reply to Paul L from comment #2)
Steps to reproduce still reproduce for me in release builds after the commit (23 and 24 May, Mac and Windows).

Comment 4 Paul L 2016-06-23 23:17:50 UTC

Try again:
https://github.com/audacity/audacity/commit/79eeb03a5002dfd917f4ab390c0d042e41280b59

Comment 5 Peter Sampson 2016-09-21 13:16:14 UTC

Tested on W10 audacity-win-rf993f1e-2.1.3-alpha-20-sep-16 
and on Mac El Capitan 285f6dc 21Sep16

On both platforms exporting does not appear to make a formerly clean project "dirty"

1) Open Audacity
2) import a WAV file
3) Save the project
4) export the audio to different WAV or MP3
5) Close Audacity
6) No naggogram for saving project => project remained clean

If I omit step 3 (i.e. project "dirty" before the export) then after step 5 I do get the naggogram implying that the project reamined "dirty" and that the export did not "clean" it.

Comment 6 Gale Andrews 2016-10-19 13:42:13 UTC

Seems OK this time. 

Navigating Metadata Editor fields or clicking them without typing correctly does not make the project dirty. 

Typing in the fields still does make the project dirty (during export or when editing without export). 

Bug 1327 and Bug 1337 are still fixed.

Comment 7 Steve Daulton 2016-12-21 07:10:53 UTC

Reopened as the fix breaks bu 440.

Comment 8 Steve Daulton 2016-12-21 07:11:41 UTC

(In reply to Steve Daulton from comment #7)
bug 440.

Comment 9 Gale Andrews 2016-12-21 09:35:21 UTC

(In reply to Steve Daulton from comment #8)
Is it the correct policy to reopen this? I would have thought not, so I have set it back to RESOLVED - QUICKFIXED. This bug is still fixed, but bug 440 won't be fixed for 2.1.3, so reopening this would mean an incorrect release note item. 

Of course, this bug must be retested when bug 440 is fixed, but that can be noted as a test requirement in bug 440.

Comment 10 Steve Daulton 2016-12-21 10:09:28 UTC

(In reply to Gale Andrews from comment #9)
> Is it the correct policy to reopen this?

I would have thought so, because this fix is wrong. It incorrectly removes new tags if they do not have a "value". (Tags are name/value pairs, but we want to save the tag even if the value is not set).