Topic: Updating tags is slow (Read 7127 times)

soylent::black · « **on:** May 11, 2004, 03:55:35 pm »

I know somebody has to of asked this previously but I just can't seem to find any old threads on it:

Updating tags (Updating tags changes) takes several minutes per file, both formats: mp3 & ogg.

It also puts a severe strain on the system (Windows 2000) and everything just about freezes up. A long time ago this did not happen.

I have fixed my drives, they are back up to Ultra DMA mode, and that helped with playback and ripping but not the tag update problem...

Any ideas?

James

Matt · « **Reply #1 on:** May 11, 2004, 04:17:24 pm »

Tagging OGG always rewrites the file. It's a limitation of the most recent OGG SDK.

MP3 files can be slow to be tagged when there isn't an ID3v2 tag. Subsequent updates will be fast.

Use Action Window > File Properties > File Type Info to see exactly what you have.

MP3 tagging is configurable in Plugin Manager.

soylent::black · « **Reply #2 on:** May 11, 2004, 05:18:59 pm »

But should it be this slow? It just took 6 1/2 minutes to rename 8 mp3 files. During this time other programs become basically unusable, and playback eventually stops.

And just to be sure I just renamed the same 8 files again and it still took 6 1/2 minutes.

And then I modified options to "Don't Save" idv1 tags (ignore) just for kicks, and tried it again. No change.

I have a Pentium III 800 Mhz. A rather old machine but like I said this did not use to happen. It just seems to get slower & slower & slower...

Matt · « **Reply #3 on:** May 11, 2004, 05:20:57 pm »

Disable ID3v2 tag writing and see if it's still slow.

However, that sounds like something else on your computer is going wrong. (like PIO mode, slow network, etc.)

grahamk · « **Reply #4 on:** May 12, 2004, 09:39:35 am »

All my mp3 files have V2 tags. Updating tags on my system is still painfully slow.

I just updated ~20,000 tags - it took about 24 hours. That's ~14 tags per minute.

On a related topic - I decided to "get smart" and changed the "update tags when file info changes" to off. Then I updated a ton of files and performed a "update tags from library". To my astonishment, when it was done the tags were all back to what they were before I did the update. Should this have worked? If not, is there a way to change a bunch of tags in the library and have them batched out at the end instead of wating for each tag to be updated?

Thx,
Graham

Matt · « **Reply #5 on:** May 12, 2004, 10:07:28 am »

Tagging shouldn't be that slow.

See if the file is getting rewritten by checking if the ID3v2 tag size changes between tags. (AW > File Type Info) It shouldn't unless you're adding or removing lots of info or images.

Also, "Update Tags (from files)" will rewrite the tags using the current library info. If this doesn't work, please start another thread so we can troubleshoot.

GHammer · « **Reply #6 on:** May 12, 2004, 11:19:47 am »

Quote from: Matt on May 12, 2004, 10:07:28 am

Also, "Update Tags (from files)" will rewrite the tags using the current library info. If this doesn't work, please start another thread so we can troubleshoot.

I know what you mean, but to be clear isn't it Update Tags (from library)?

JimH · « **Reply #7 on:** May 12, 2004, 02:36:21 pm »

If you think tagging is slow, please provide a little more detail. Are the files stored on a network drive, for example?

And please copy your system info from MC Help and paste it here.

grahamk · « **Reply #8 on:** May 12, 2004, 04:48:02 pm »

My files are on a Network Appliance F880 filer. The filer isn't breaking a sweat. I regularly push 12MB/second between the filer and my windows box. The filer itself is capable of well over 100MB/second. Here is what the filer is doing during a tag update:

CPU Total Net kB/s Disk kB/s Cache Cache CP CP Disk
ops/s in out read write age hit time ty util
11% 536 190 2428 3048 1084 >60 100% 16% 12%
4% 65 115 1586 1612 0 >60 98% 0% - 6%
6% 75 120 2120 2008 0 >60 98% 0% - 5%
6% 88 134 2473 2424 0 >60 98% 0% - 7%
6% 102 180 2198 2132 0 >60 98% 0% - 7%

This windows box (MC Help info is pasted below) is only seeing about 20% CPU usage during a tag update. So I'm at a bit of a loss at to where the lag is coming into play....

Anything you can tell me to help speed this up would be greatly appreciated. Thanks for your responsiveness.

Graham

Media Center 10.0.127 -- C:\Program Files\J River\Media Center\

Microsoft Windows 2000 Workstation 5.0 Service Pack 4 (Build 2195)
AMD Athlon 1993 MHz MMX / Memory: Total - 785 MB, Free - 557 MB

Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.81 / Shlwapi.dll: 6.00.2800.1400 / Shell32.dll: 5.00.3700.6705 / wnaspi32.dll: Internal ASPI Layer

Ripping / Drive D: Mode:Normal Type:Auto Speed:Max
Drive E: Mode:Normal Type:Auto Speed:Max
Digital playback: Yes / Use YADB: Yes / Get cover art: No / Calc replay gain: No / Copy volume: 32767
Eject after ripping: No / Play sound after ripping: No

Burning / Drive D: _NEC DVD_RW ND-2500A Addr: 1:0:0 Speed:32 MaxSpeed:32 BurnProof:Yes
Drive E: PLEXTOR CD-R PX-320A Addr: 1:1:0 Speed:20 MaxSpeed:20 BurnProof:Yes
Test mode: No / Eject after writing: Yes / Direct decoding: No / Write CD-Text: No
Use playback settings: Yes / Normalization: None

JimH · « **Reply #9 on:** May 12, 2004, 04:50:00 pm »

Just for test purposes, try setting up a local library to see how it performs.

molex · « **Reply #10 on:** May 12, 2004, 07:02:23 pm »

I've got exactly the same problem.
I run MC 10 to manage the media on my H120. Writing tags takes approx. 2-4 times longer than it does in WMP (depending on if I have album images stored or not. Mostly I do)
Storing the files locally doesn't make an appreciable difference. Also, when I update tags, I can't access MC at all and I can't refresh back to the desktop.
Please tell me what I can do to make the process go faster without turning off the tagging information.

Media Center Registered 10.0.116 -- C:\Program Files\J River\Media Center\

Microsoft Windows XP 5.1 Service Pack 1 (Build 2600)
Intel Pentium 4 1687 MHz MMX / Memory: Total - 523 MB, Free - 277 MB

Internet Explorer: 6.0.2800.1106 / ComCtl32.dll: 5.82 (xpsp1.020828-1920) / Shlwapi.dll: 6.00.2800.1400 / Shell32.dll: 6.00.2800.1106 (xpsp1.020828-1920) / wnaspi32.dll: N/A
Ripping / Drive D: COMPAQ CD-ROM CRD-8484B Mode:Normal Type:Auto Speed:Max
Digital playback: Yes / Use YADB: Yes / Get cover art: No / Calc replay gain: Yes / Copy volume: 32767
Eject after ripping: Yes / Play sound after ripping: No

Burning / No burners found.
Test mode: No / Eject after writing: Yes / Direct decoding: Yes / Write CD-Text: Yes
Use playback settings: No / Normalization: None

JimH · « **Reply #11 on:** May 12, 2004, 08:00:18 pm »

Quote from: molex on May 12, 2004, 07:02:23 pm

Writing tags takes approx. 2-4 times longer than it does in WMP (depending on if I have album images stored or not.

That may just be the difference between ID3V1 and ID3V2 tags.

Matt · « **Reply #12 on:** May 12, 2004, 08:41:44 pm »

Try to isolate what is slow. File location, internal images, etc. We need more details about what causes the slowdown.

You should be able to tag around 100 files a second on a modern computer if you don't need to create the ID3v2 tag.

jleerigby · « **Reply #13 on:** May 13, 2004, 07:43:02 am »

I've had this problem before when tagging across a network drive. I gave up in the end. Here's the thread.

Arian Haeser · « **Reply #14 on:** May 13, 2004, 08:01:26 am »

I've also propblems with updating tags. My media is on a dedicated file / internet server (P3 / 500Mhz / 512Mb / Win2K Server SP4 / 100mbit NET)

Workstation: P4 / 1.7Ghz / 512Mb / XP Pro SP1 / 100Mbit

Somethimes it will be very fast a little 1-5 seconds for 200 files but sometimes 2 minutes for one file..

I've read somewhat about ID3v2 tags on this thread.. Is it the first time slow (will MC10 always rewrite v1 to v2 or so ?)

grahamk · « **Reply #15 on:** May 13, 2004, 08:35:09 am »

All of the files I am seeing slowness with already have V2 tags.

I am going to try a small library on local disk (as soon as a tag update I started yesterday is finished). But that's really not an option for me, I need my files on a mapped network drive.

I'm curious if JRiver tests on mapped drives. I'm guessing from the recent thread about database sizes that more and more people will be using network drives.

Graham

JimH · « **Reply #16 on:** May 13, 2004, 08:58:24 am »

If it does turn out to be associated with network drives, it may not be within our control. It may be a Microsoft problem.

Matt · « **Reply #17 on:** May 13, 2004, 09:25:39 am »

Please answer these questions if tagging is slow for you:

1) How many files a minute can MC tag?
2) What format are you tagging?
3) Where do you store your files (local / server) and how fast is that drive / machine?
4) If you do "Library Tools > Update Tags (from library)" on a set of files, is the speed consistent, or is it much faster the second time for the same set of files?

Thanks for helping everyone.

RhinoBanga · « **Reply #18 on:** May 13, 2004, 11:55:02 am »

Quote from: Arian Haeser on May 13, 2004, 08:01:26 am

I've also propblems with updating tags. My media is on a dedicated file / internet server (P3 / 500Mhz / 512Mb / Win2K Server SP4 / 100mbit NET)

Workstation: P4 / 1.7Ghz / 512Mb / XP Pro SP1 / 100Mbit

Somethimes it will be very fast a little 1-5 seconds for 200 files but sometimes 2 minutes for one file..

I've read somewhat about ID3v2 tags on this thread.. Is it the first time slow (will MC10 always rewrite v1 to v2 or so ?)

Is your windows server a domain controller? I had a similar problem (slow writing to my file server ages ago) and it was because MS throttle back the SMB protocol:

Workaround 1
HKEY_LOCAL_MACHINE\System\CCS\Services\LanmanServer\Parameters
Double-click the RequireSecuritySignature value, type 0 in the Value data box, and then click OK.
Double-click the EnableSecuritySignature value, type 0 in the Value data box, and then click OK.

Set TcpDelAckTicks to 0

If you set the TcpDelAckTicks value to 0, you turn the timer off completely. When the timer is turned off, TCP reverts to pre-Request for Comments (RFC) 1122 behavior; it acknowledges each packet. This workaround solves the SMB copy performance issue. However, on a high latency network (highly saturated segment), this behavior increases the number of acknowledgements from the domain controller and puts additional strain on the network.

Do a search for TcpDelAckTicks in Google for loads of info on this.

Arian Haeser · « **Reply #19 on:** May 13, 2004, 12:10:13 pm »

Hi,
Yes my Windows 2000 Server is a PDC.

but for me the problem is fixed. I've selected all the files (5000+) and filled the mood tag with 'test'. This takes a hour of 2 - 3, but now it is fast enough to work with. (do MC rewrite always as id3v2 or so?)

So I think it was the id3v1 / v2 problem. Now it goes with a speed of 10 tags a second.

But I've a little more information. On my windows 2k server I run a software firewall / router (Winroute Pro http://www.kerio.com/wrp_home.html)

At the time I'm updating tags the winroute.exe process goes from 00-01% processor usage to 30-40%. Als the process called 'System' goes up to around 20% (but i think thats ok)

I can't see why my winroute is used while writing tags.. But I'm sure that is not a problem in MC.

grahamk · « **Reply #20 on:** May 17, 2004, 08:34:04 pm »

I finally got around to looking at this some more.

I used a test set of 20 files and timed updating the tags.

When they are on a file server (Netapp F880 - very high performance system) it takes 67 seconds to update the tags on the files (V2). I reran the test 3 times by just adjusting the album name by 1 character and it took the same amount of time to update the tags.

Doing this to local disk took less than a second.

Local disk isn't an option for me. Looks like it is certainly a network drive issue though.....

Graham

JimH · « **Reply #21 on:** May 17, 2004, 09:03:32 pm »

Quote from: grahamk on May 17, 2004, 08:34:04 pm

Local disk isn't an option for me. Looks like it is certainly a network drive issue though.....

If it is, it is probably completely out of our control.

grahamk · « **Reply #22 on:** May 17, 2004, 10:04:19 pm »

I sure hope not. Lots of applications work perfectly well with mapped network drives, and since music databases are getting larger and larger I think it would behoove you to make sure your application works at least *reasonably* well with a mapped network drive too. I'm not asking for lightning speed (although that certainly should be possible) just something a bit faster than paint drying. :-)

Graham

rolf_eigenheer · « **Reply #23 on:** January 02, 2005, 04:11:26 am »

Quote from: JimH on May 17, 2004, 09:03:32 pm

If it is, it is probably completely out of our control.

This is definitivly NOT out of your control! MC9 had no problem tagging >90'000 files on a 1.5TB raid array (linux/smb).

MC10 looses tags while importing from a network drive, generates invalid filenames when renaming from tags, updates tags very slow (several seconds per mp3). Files are fully rewritten every time a tag changes (even there changes just one character)

Rolf

JimH · « **Reply #24 on:** January 02, 2005, 07:16:44 am »

Have you tried MC11? Tagging is done in a separate thread.

rolf_eigenheer · « **Reply #25 on:** January 02, 2005, 09:29:56 am »

Quote from: JimH on January 02, 2005, 07:16:44 am

Have you tried MC11? Tagging is done in a separate thread.

Hi Jim,
I'm happy to see that you arrived well in the new year...

I tried MC11, but I didn't allow MC11 to modify the tags. So I tried importing 1000 MP3s.
It took a long time (more than 10 minutes). Longer tag values have been truncated at 32 chars.
It looked like V1 tags, but MC9 and other players can read the V2 tags.

I suppose MC10/11 has a problem reading the V2 tags. And therefore it tries to generate V2 tags. Saving the tags takes a long time. During this seconds you'll find a temporary file with a XXXXX extension on disk. This happens every time I change a single character.

There are also some few files which can be read and written without problems. So it could be a confliicht with character set handling in the filesystem. But why does this also occur when saving tags inside an existing file, without renaming ?

Shall I supply some Files and a database to demonstrate the problem ?

JimH · « **Reply #26 on:** January 02, 2005, 10:16:45 am »

What version of MC did you try?

More recent versions of MC do analysis of files when they import, so files are read and re-written. On a network this can be slow.

Did you try it locally?

rolf_eigenheer · « **Reply #27 on:** January 02, 2005, 10:28:21 am »

I tried todays MC11 11.0.162

This version like the latest MC10 10..0.173 can't import V2 tags from files located on a network drive.

MC9 9.1.316 is the latest Version working fine.

rolf_eigenheer · « **Reply #28 on:** January 02, 2005, 10:53:52 am »

regarding your question...

No I didn't try it locally. The network drive holding my files is write protected (since MC10 killed several thousend files).

With MC10 10.0.173 I made some more tests. I moved some directories which failed to import correctly to a local drive. There it worked fine - but this is useless, because my local drive cant't hold all my files.

For the moment I'm using MC9 to import/organize and MC10 to access/listen.

JimH · « **Reply #29 on:** January 02, 2005, 12:21:27 pm »

If it works locally, but not from the network drive, it could be a bug or a problem somewhere else (and not in MC).

rolf_eigenheer · « **Reply #30 on:** January 02, 2005, 02:59:44 pm »

Quote from: JimH on January 02, 2005, 12:21:27 pm

If it works locally, but not from the network drive, it could be a bug or a problem somewhere else (and not in MC).

Sure, it could be the problem of anyone else. But believe me: Dozens of other applications can open, read and write files over a network connection. Even MC9 could!
This problem has also been reported by users, which use windows fileservers.
Please help us solving this problem. MC is the greatest Multimeadia Aplication. I found nothing else which could handle so much files and is still fast. But Network support is essential!
Do you have debug Versions, which log access to the filesystem ?

rolf_eigenheer · « **Reply #31 on:** January 14, 2005, 04:21:58 pm »

this thread is not closed!

see "MP3 file problems with MC10" things discussed there are concerning the same problem

Rolf

cfgreen · « **Reply #32 on:** January 14, 2005, 04:48:21 pm »

My Two Cents;

I found tagging files on the server is very slow, my best bet ended up to do this on the local fast drive.
(this really helps on the file rewrite!) Also cut way down on having to defrag the server drives.

Then move the Dirs/files to the server, and import those dir's only.

Has led to a neater workflow.

tlongacre · « **Reply #33 on:** January 14, 2005, 05:49:33 pm »

I find updating tags slow on my system as well. Definitely faster on the local machine than via the mapped network drives. But, I'm with Rolf, I don't really know why this has to be. I do not have any experience of slowdown with other files (for instance, photo files accessed, edited and managed via Adobe Photoshop or Album v.2). Playing music files in MC is not noticeably slower. But tagging definitely is. Now that tagging happens in the background, I don't notice it as much (before it went into the background, I would practically cry with frustration 'cause my whole system would be locked). When I go to close MC, though, it is almost always still tagging files. . .

This problem definitely started with MC11 (maybe somewhat with 10, but it wasn't so noticeable for me until 11).

Just wanted to chime in.

BTW, my system is a Linksys Network device that had 2 Maxtor HDDs on it.

INTERACT FORUM

Author Topic: Updating tags is slow (Read 7127 times)

jleerigby