"Fran Burstall (Gmail)" <[email protected]> writes: > On Wed, 17 Feb 2021 at 21:56, Yoni Rabkin <[email protected]> wrote: > >> >> >> Can you please try again with a larger frame size limit? >> >> (setq emms-info-native--max-peek-size (expt 2 22)) >> >> >> > (setq emms-info-native--max-peek-size (expt 2 22)) reduces the fails from > 75 to 15 at the cost of a massive slowdown (52sec for 75 files) > > (setq emms-info-native--max-peek-size (expt 2 24)) reduces the fails from > 15 to zero at the cost of another massive slowdown (69sec for 15 files) > > I wonder if one could dynamically and temporarily increase peek size in > reaction to frame size errors?
I was thinking the exact same thing when I read the first line you wrote. The frame-size error needs to be caught and then the read retried with a higher value until either a success or a critical limit is reached. To avoid trashing Emacs and the user's memory the process should critically terminate when it gets to, say, half the size of your average mp3, or half the file size if we that on hand. This is since I can go ahead and assume that there aren't many mp3s out there where half of the file is metadata. Petteri, what do you think of the dynamic-scaling idea? -- "Cut your own wood and it will warm you twice"
