https://bugs.kde.org/show_bug.cgi?id=526714

Tuomas Nurmi <[email protected]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|MySQLe query out of range   |Wish: More readable
                   |value for column            |user-facing error messages
                   |'changedate'                |on database errors
                 CC|                            |[email protected]

--- Comment #1 from Tuomas Nurmi <[email protected]> ---
(In reply to Mehrad Mahmoudian from comment #0)
> DESCRIPTION
> 
> I store my purchased music on the cloud and typically I Sync them, but this
> time I downloaded them as a Zip file and extracted locally and Amarok threw
> the following error:
> 
> > MySQLe query failed! (1264) Out of range value for column 'changedate' at 
> > row 1 on INSERT INTO directories(deviceid,changedate,dir) VALUES 
> > (1,18446744071562067968,'user/Music/Artist/Album');
> 
> The reason is that the folder's modified file is "Friday, 13 December 1901
> 22:25:41 HMT". I don't know why this happens, but I believe throwing such
> ambiguous error to end user that might not be tech-savvy enough is not the
> best approach. I suggest Amarok checks the data before pushing it to
> database, and if error occurs, it generates a more human-readable error.
> 
> STEPS TO REPRODUCE
> 1. store multiple audio files on Google Drive in a folder
> 2. Download the folder as a Zip file
> 3. Extract it on the computer (I used KDE Dolphin > right click on the file
> > extract > extract here)
> 4. in Amarok's menu: Tools > Update Collection
> 
> OBSERVED RESULT
> 
> > MySQLe query failed! (1264) Out of range value for column 'changedate' at 
> > row 1 on INSERT INTO directories(deviceid,changedate,dir) VALUES 
> > (1,18446744071562067968,'user/Music/Artist/Album');
> 
> 
> EXPECTED RESULT
> 
> Skip the problematic file/folder and continue updating database without
> error, and then a human readable error to explain the user what the issue
> is. For example:
> 
> > The folder 'user/Music/Artist/Album' has invalid Modification Time.
> 
> SOFTWARE/OS VERSIONS
> Operating System (available in the Info Center app, or by running `kinfo` in
> a terminal window):
> Operating System: EndeavourOS
> KDE Plasma Version: 6.7.5
> KDE Frameworks Version: 6.30.0
> Qt Version: 6.11.2
> Kernel Version: 6.18.55-1-lts (64-bit)
> Graphics Platform: Wayland
> Processors: 20 × Intel® Core™ i9-10900K CPU @ 3.70GHz
> Memory: 32 GiB of RAM (31.0 GiB usable)
> Graphics Processor 1: Mesa Intel® UHD Graphics 630
> Graphics Processor 2: AMD Radeon Pro WX 3200 Series
> 
> ADDITIONAL INFORMATION
> 
> I managed to create a reproducible exmaple using a public domain audio file
> downloaded from here:
> https://librivox.org/the-adventures-of-sherlock-holmes-version-6-dramatic-
> reading-by-sir-arthur-conan-doyle/
> 
> but the file size (24.6MB) is larger than the limit here (4MB), so I have no
> choice but to share it from my Google drive:
> 
> https://drive.google.com/file/d/1L0qogaDycmlGydv30bYsYfpjO5Ak7jp3/
> view?usp=sharing
> 
> This is the error that Amarok 3.3.3 throws when the file is extracted:
> 
> > MySQLe query failed! (1264) Out of range value for column 'changedate' at 
> > row 1 on INSERT INTO directories(deviceid,changedate,dir) VALUES 
> > (1,18446744071562067968,'mehrad/Music/KDE-Amarok-bug-report/test');


Couldn't reproduce just by extracting the zip. I managed to reproduce by
manually altering the file's modified date to early 1900's.

The bug title suggests that this report is about the error during saving, but
your description reads more like a request for more descriptive user-visible
error messages on database errors. I will edit the bug title accordingly.
However, I will also note that as there are arbitrary number of different
errors the database backends could produce in various situations, and they're
reported as somewhat free-form strings, providing specifically handled, easily
readable, translated user-facing strings for any error is unrealistic.

(Regarding the actual error: Slightly related earlier fix for "y2038" problem
at https://bugs.kde.org/show_bug.cgi?id=426807
Even by using the date datatype, tracks would be limited to dates later than
year 1000, see e.g.
https://dba.stackexchange.com/questions/7077/best-way-to-handle-dates-prior-to-1000-a-d-in-mysql
).

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to