IPB

Welcome Guest ( Log In | Register )

> foobar2000 Tech Support Forum Rules

Please read foobar2000 Tech Support Forum Rules before posting and comply with all the points.
Failure to provide all the information pointed out in the above document in your post is considered wasting other people's time and in extreme cases will lead to your topic getting locked without a reply.


See also: Hydrogenaudio Terms of Service.

 
Reply to this topicStart new topic
Batch attach pictures greyed out
SigHunter
post Jun 16 2013, 18:30
Post #1





Group: Members
Posts: 48
Joined: 22-September 08
Member No.: 58544



Hey there,

since some Foobar versions the "batch attach pictures" function only works for a limited count of files.

i used to be able to select all my files in playlist/library (~4k) and do the batch attach pictures thingy.

however now it is greyed out, for some reason. when i select fewer songs (like 500) its black and works as before.

why is that and why doesn't it work as it used to?

500 files:


4000 files:



edit:
tested it with a portable installation of 1.1.12, there it works, another portable (completely empty) install of 1.2.8, its grey as stated above

This post has been edited by SigHunter: Jun 16 2013, 18:41
Go to the top of the page
+Quote Post
dhromed
post Jun 18 2013, 16:16
Post #2





Group: Members
Posts: 1308
Joined: 16-February 08
From: NL
Member No.: 51347



Some of the files in the selection do not support attaching pictures?
Go to the top of the page
+Quote Post
SigHunter
post Jun 18 2013, 20:51
Post #3





Group: Members
Posts: 48
Joined: 22-September 08
Member No.: 58544



QUOTE (dhromed @ Jun 18 2013, 17:16) *
Some of the files in the selection do not support attaching pictures?

well, i only have flac + mp3s, and the same files work with foobar 1.2.0 and before.

is there some bugtracker or some way i can report this bug? (i think its a bug)
Go to the top of the page
+Quote Post
Peter
post Jun 19 2013, 10:03
Post #4


foobar2000 developer


Group: Admin
Posts: 3276
Joined: 30-September 01
Member No.: 84



Rationale: when working on really large groups of files (100000 and more), certain seemingly harmless operations cause foobar2000 UI to lag.
In this case, checking if every file on the list supports album art operations caused UI lag before the context menu appeared. I added a workaround: the commands get grayed out if you select more than 1000 items as it seemed unlikely to me that anyone would want to batch attach pictures to so many files at once. I'll increase the limit for the next version so it hopefully does not bother you again.
If you wish to batch attach files to so many files in one pass, please tell me why exactly you want to do such thing and I'll take it into consideration.
Go to the top of the page
+Quote Post
dhromed
post Jun 19 2013, 11:53
Post #5





Group: Members
Posts: 1308
Joined: 16-February 08
From: NL
Member No.: 51347



QUOTE (Peter @ Jun 19 2013, 11:03) *
If you wish to batch attach files to so many files in one pass, please tell me why exactly you want to do such thing and I'll take it into consideration.


I can select any number of items, and do things to them. Foobar has a strong reputation for being super-fast and being able to handle very large amounts of items in a playlist, so it's not immediately obvious that adding images would cause problems. If it takes time-- that's okay. Converting 4000 items also takes time. RG-scanning 4000 items also takes time. Why block the user for this one action?
Go to the top of the page
+Quote Post
ruebe
post Jun 19 2013, 13:02
Post #6





Group: Members
Posts: 187
Joined: 18-September 10
Member No.: 83940



QUOTE (dhromed @ Jun 19 2013, 12:53) *
If it takes time-- that's okay.


i beg to differ. i did numerous things with foobar, that took quite a considerable amount of time, e.g. mass deleting of unused tags, mass verification of integrity, mass moving
every now and then i want to stop/pause/cancel such operation and run into severe downside
for example, if i'm running a mass moving operation and i have stop it for whatever reaseon, there is no chance i can find out, practically that is, which items have already been moved
OTOH, mass operations can be problematic per se, e.g. mass verifing of integrity is completely useless, because the output is neither search- nor sortable

now, on the topic at hand; if someone is mass batch attaching pictures and has to stop for whatever reason in the middle, there is no way to find out to which songs pictures have not been added yet
with this in mind, i'm inclinded to think that preventing (too) obsesive operations help users to keep their sanity
Go to the top of the page
+Quote Post
Rollin
post Jun 19 2013, 14:42
Post #7





Group: Members
Posts: 191
Joined: 5-March 08
Member No.: 51815



QUOTE (ruebe @ Jun 19 2013, 16:02) *
mass verifing of integrity is completely useless, because the output is neither search- nor sortable

You can export log of verification to simple txt file. All "bad" files will be listed in the end of log. It is very search- and sortable.
Go to the top of the page
+Quote Post
Silversight
post Jun 19 2013, 15:23
Post #8





Group: Members
Posts: 310
Joined: 5-April 06
From: Aachen, Germany
Member No.: 29203



Since the cause for the UI lag is a mass feature check on the selected files, maybe foobar2000 could only check if a file supports album art during the process immediately before it tries to write the album art to the file. This has multiple benefits:
  • Pictures could be attached to many files even when one of them doesn't support album art
  • No UI lag (of course)
  • Possible console output of non-working files (and reasons why)
  • More consistency across different features after all, the Properties window doesn't deactivate the OK/Apply buttons when one or all of the files is/are read-only. Same with the RG scanner.


--------------------
Nothing is impossible if you don't need to do it yourself.
Go to the top of the page
+Quote Post
lvqcl
post Jun 19 2013, 15:27
Post #9





Group: Developer
Posts: 3371
Joined: 2-December 07
Member No.: 49183



QUOTE (dhromed @ Jun 19 2013, 14:53) *
Why block the user for this one action?

To prevent a noticeable pause between right-click and context menu appearance.
Go to the top of the page
+Quote Post
ruebe
post Jun 19 2013, 15:34
Post #10





Group: Members
Posts: 187
Joined: 18-September 10
Member No.: 83940



QUOTE (Rollin @ Jun 19 2013, 15:42) *
QUOTE (ruebe @ Jun 19 2013, 16:02) *
mass verifing of integrity is completely useless, because the output is neither search- nor sortable

You can export log of verification to simple txt file. All "bad" files will be listed in the end of log. It is very search- and sortable.

to my defense, i was talking about the pop up window
beyond that: my bad, i apparently misread a few lines in the log file; however, i wouldn't call a log file an interactive enviroment, and thus think that the pop up window could be improved, but that's off topic

anyway, sorry for making false claims; i however hope that this does not invalidate my initial post as a whole
Go to the top of the page
+Quote Post
dhromed
post Jun 19 2013, 17:11
Post #11





Group: Members
Posts: 1308
Joined: 16-February 08
From: NL
Member No.: 51347



QUOTE (ruebe @ Jun 19 2013, 14:02) *
QUOTE (dhromed @ Jun 19 2013, 12:53) *
If it takes time-- that's okay.

now, on the topic at hand; if someone is mass batch attaching pictures and has to stop for whatever reason in the middle, there is no way to find out to which songs pictures have not been added yet
with this in mind, i'm inclinded to think that preventing (too) obsesive operations help users to keep their sanity


I see what you mean, but disabling a menu item at some random "reasonable" item count is definitely not the solution to that specific problem.

QUOTE (lvqcl @ Jun 19 2013, 16:27) *
QUOTE (dhromed @ Jun 19 2013, 14:53) *
Why block the user for this one action?

To prevent a noticeable pause between right-click and context menu appearance.


That seems a very silly reason to me.

The crux of the problem is this:
QUOTE
In this case, checking if every file on the list supports album art operations caused UI lag before the context menu appeared


I don't think picking a number on a whim is a reasonable workaround to this problem. I understand the desire is to have a dynamic context menu that responds to the capabilities of the selected items, but why not give that up, display the option at all times, and let the output popup tell the user which items were processed and which were skipped?

I also think it's bad UX if there could be 1 unknown item in a large selection that spoils a user's ability to make some change.
Go to the top of the page
+Quote Post
Peter
post Jun 19 2013, 20:31
Post #12


foobar2000 developer


Group: Admin
Posts: 3276
Joined: 30-September 01
Member No.: 84



I've changed the feature to give up checking whether files support album art operations or not after N items instead. The next update will have the fix. Thanks for bringing it up.
Go to the top of the page
+Quote Post
SigHunter
post Jul 4 2013, 21:32
Post #13





Group: Members
Posts: 48
Joined: 22-September 08
Member No.: 58544



QUOTE (Peter @ Jun 19 2013, 21:31) *
I've changed the feature to give up checking whether files support album art operations or not after N items instead. The next update will have the fix. Thanks for bringing it up.

awesome, thank you!
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 2nd September 2014 - 17:50