Opened 17 years ago

Closed 17 years ago

#2744 closed patch (fixed)

Scalability patch for mythmusic cd-import / ripping function.

Reported by: frank.lynch@… Owned by: paulh
Priority: minor Milestone: unknown
Component: mythmusic Version: 0.20
Severity: medium Keywords:
Cc: Ticket locked: no

Description

The attached patch introduces a new configuration option for mythmusic, under ripper settings it is a simple check-box called "Rebuild music tree after cd rip" and is set to true by default (preserving the existing behavior). Setting this variable to false postpones the rebuilding of the music tree. The user will have to manually do a "scan for new music" with mythmusic after importing/ripping cd's.

I created this patch because I have quite a large music collection, it was taking 15 mins or so to rebuild the music library after each cd rip. With this patch I can now import/rip 10 cd's without waiting around for a db rebuilds between rips.

This patch applies cleanly to mythmusic in the current svn head and the 0.20 fixes branch.

Attachments (1)

patch.diff (2.0 KB) - added by frank.lynch@… 17 years ago.
Simple patch to permit the importing of multiple cd's without rebuilding the db between each rip.

Download all attachments as: .zip

Change History (6)

Changed 17 years ago by frank.lynch@…

Attachment: patch.diff added

Simple patch to permit the importing of multiple cd's without rebuilding the db between each rip.

comment:1 Changed 17 years ago by anonymous

Summary: Scalability paity, or milestone from the defaults. These fields are for the person who is fixing the issue to decide. Don't change these after the ticket's been filed, either - they'll likely just get changed back.tch for mythmusic cd-import ripping function.Scalability patch for mythmusic cd-import / ripping function.

updated / fixed the subject for this ticket.

comment:2 Changed 17 years ago by paulh

Owner: changed from Isaac Richards to paulh

comment:3 in reply to:  2 Changed 17 years ago by Dibblah

I don't really like this solution, since it's a bandaid.

Would it be possible instead to repurpose date_modified in the music_songs table so it's the actual timestamp from the file and avoid metadata checking if this is the same?

comment:4 Changed 17 years ago by stuartm

Milestone: unknown

comment:5 Changed 17 years ago by paulh

Resolution: fixed
Status: newclosed

(In [12582]) The main focus of this commit is to make mythmusic's rip screen more remote friendly and to allow you to rip several CD'S without having to do a full rescan after each one. Closes #2744.

Main changes are:-

  • Change the rip dialog and the progress dialog to MythThemedDialogs? so they are themeable.
  • Make the dialog fully remote friendly - doesn't use the MythTable? that was virtually impossible to use without a keyboard and mouse.
  • You can now rip more than one CD consecutively without closing the dialog.
  • No need to perform a re-scan after ripping a CD - after each track is ripped its metadata is inserted into the DB.
  • Allow for more complex filenames to be generated with more than one token per section. (Patch from tlawton) Closes #2925
  • Give better feedback to the user when performing tasks which may take a while to perform like scanning a CD for tracks or ejecting the CD.
  • Allow you to use the full metadata editor to change any of the metadata fields. (Highlight the track in the list then press SELECT).
  • Remove the "Only Rip New Music" setting its no longer needed. If MythMusic thinks that one or more tracks are already in the database it will ask you what you want to do.
Note: See TracTickets for help on using tickets.