Yoni Rabkin <[email protected]> writes: > Perhaps it would be good to update the other pieces of metadata when the > comment is too long so that the user still gets the benefit of playing > time, title and etc.
This is doable. Now the code is short-circuiting in the sense that whenever there is an error processing a file, it just bails out for that file. It wouldn't need to be like that. We could try to extract as much usable data as possible. As for the limits for comment field lengths etc, they are nowadays more or less obsolete. The rationale for limits was that bindat-unpack function could hog excessive amounts of memory when reading data to elisp vectors. Now most of the variable length vectors have been replaced by strings, which do not have that issue. So almost all of the limits could be removed, which I will do soon. It is also the right thing to do because e.g. many cover art metadata blocks can span hundreds of kilobytes. emms-info-native cannot yet extract them, but it should not error (and consequently give up) either. > It also makes me wonder if it makes sense to add a debug field to the > metadata when there is an error, and store error information in > there. That way it would be very easy indeed to figure out if any errors > occurred during reading just by looking for any tracks with a 'debug > symbol in their track alist. Just an idea. This might be useful for debugging, perhaps via some defcustom, but I wouldn't store that kind of information in regular use. But the idea is interesting, I'll keep it in my mind. Thanks, Petteri
