Bug 323344

Summary: CD ripping: When you cancel ripping, K3b forgets user-entered metadata and reloads all from CDDB
Product: [Applications] k3b Reporter: Claus Appel <spectrumdt>
Component: CopyingAssignee: k3b developers <k3b>
Status: REPORTED ---    
Severity: normal CC: hpfeil, trueg
Priority: NOR    
Version: 2.0.2   
Target Milestone: ---   
Platform: Debian stable   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description Claus Appel 2013-08-10 14:12:18 UTC
When ripping CDs, K3b by default tries to fetch metadata from CDDB. When it has fetched CDDB data, the user is able to edit the metadata manually. But if you start ripping and then cancel ripping (either deliberately or because an error occurred), K3b forgets all edits that the user has made, and simply reloads all metadata from CDDB. 

This is particularly problematic in conjunction with bug 323343 (which often causes ripping to fail): https://bugs.kde.org/show_bug.cgi?id=323343

This is related to bug 271134 "Save CDDB entry locally does not work", which I reported two years ago and which has remained untouched: https://bugs.kde.org/show_bug.cgi?id=271134

Reproducible: Always

Steps to Reproduce:
1.
Insert any audio CD.
2. Open K3b.
3.
Go to "Rip Audio CD..."
4. Change the title of the first track to "Foobar". 
5. Click "Start ripping".
6. In the dialog that appears, click "Start ripping".
7. Wait a moment for K3b to start ripping.
8. Click "Cancel".


Expected Results:  
The title of the first track has reverted to what is found in CDDB.

The title of the first track should still be displayed as "Foobar".
Comment 1 Andrew Crouthamel 2018-11-12 02:46:24 UTC
Dear Bug Submitter,

This bug has been stagnant for a long time. Could you help us out and re-test if the bug is valid in the latest version? I am setting the status to NEEDSINFO pending your response, please change the Status back to REPORTED when you respond.

Thank you for helping us make KDE software even better for everyone!
Comment 2 Claus Appel 2018-11-12 16:51:17 UTC
LOL. I kind of assumed that K3b wasn't being developed anymore since this bug had never gotten a comment (along with 323343 and 271134). 

I can confirm that this behaviour still happens in K3b 2.0.2 on KDE Development Platform 4.13.3 (Kubuntu 14.04).
Comment 3 Justin Zobel 2022-12-03 09:01:39 UTC
Thank you for reporting this issue in KDE software. As it has been a while since this issue was reported, can we please ask you to see if you can reproduce the issue with a recent software version?

If you can reproduce the issue, please change the status to "REPORTED" when replying. Thank you!
Comment 4 Bug Janitor Service 2022-12-18 05:14:32 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 5 Claus Appel 2022-12-25 11:21:58 UTC
I can confirm that this still happens in K3b 19.12.3 on Kubuntu 20.04.
Comment 6 Henry Pfeil 2024-05-14 16:05:32 UTC
<<necropost>>

This issue appears in duckduckgo searches. The solution is to use the floppy disk icon on the bottom left corner of the CD Ripping page that saves your Settings and File Naming changes, which remain active for the rest of the k3b session. In a new session, the curved-arrow icon next to the floppy icon restores your [multiple] saved settings.