Raspberry Pi: cue files are not shown after commit 8fa263e32d7aee22c3ea1bcea7e93ca285f00930

[eshchenko]

Steps to reproduce the problem

Compile deadbeef from fresh git on raspberry pi. Drop a directory with flac and cue files.

What's going on? Describe the problem in as much detail as possible.

Cue file is not shown:

The cue were shown correctly before commit 8fa263e32d7aee22c3ea1bcea7e93ca285f00930 8fa263e32 configure: Use AC_SYS_LARGEFILE 2023-06-12

If in the configure.ac I comment the line containing AC_SYS_LARGEFILE the cue is shown correctly:

To conclude - this roll back and the roll back described in the issue #3052 make the fresh deadbeef on raspberry pi usable: both jpeg art is scaled up correctly and cue is shown as expected:

The cue file is attached: cue.zip

Information about the software:

Deadbeef version: starting from commit 8fa263e32d7aee22c3ea1bcea7e93ca285f00930 OS: Two 32 bit Raspbian OS were tested: Compilation on Buster: uname -a Linux raspberrypi 5.10.103-v7l+ #1529 SMP Tue Mar 8 12:24:00 GMT 2022 armv7l GNU/Linux

cat /proc/cpuinfo processor : 0 model name : ARMv7 Processor rev 3 (v7l) BogoMIPS : 126.00 Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 CPU implementer : 0x41 CPU architecture: 7 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3

cat /proc/version Linux version 5.10.103-v7l+ (dom@buildbot) (arm-linux-gnueabihf-gcc-8 (Ubuntu/Linaro 8.4.0-3ubuntu1) 8.4.0, GNU ld (GNU Binutils for Ubuntu) 2.34) #1529 SMP Tue Mar 8 12:24:00 GMT 2022 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Compilation on Bookworm uname -a Linux raspberrypi 6.6.20+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07) aarch64 GNU/Linux

cat /proc/cpuinfo processor : 0 BogoMIPS : 108.00 Features : fp asimd evtstrm crc32 cpuid CPU implementer : 0x41 CPU architecture: 8 CPU variant : 0x0 CPU part : 0xd08 CPU revision : 3

cat /proc/version Linux version 6.6.20+rpt-rpi-v8 (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT Debian 1:6.6.20-1+rpt1 (2024-03-07)

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! It is interesting to note that on the "old" Intel the cue problem is not reproducible. uname -a Linux HP-EliteBook-8530p 4.2.8-040208ckt13-generic #201607131532 SMP Wed Jul 13 19:34:20 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

cat /proc/version Linux version 4.2.8-040208ckt13-generic (kernel@gomeisa) (gcc version 5.2.1 20151010 (Ubuntu 5.2.1-22ubuntu2) ) #201607131532 SMP Wed Jul 13 19:34:20 UTC 2016 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Best regards, Dmitry

[Oleksiy-Yakovenko]

@eshchenko can you try again with latest master -- commit #cbd5d9b more specifically? It's quite suspicious that only cue files stop working after the commit you referred to, which introduced the use of AC_SYS_LARGEFILE. If this fix doesn't help, I'll try to investigate more. It's problematic to revert, because in my understanding this would break musl builds. Potentially may require a special manually specified configure flag for musl users.

[eshchenko]

Dear Oleksiy I had just compiled the fresh git - Unfortunately the cue problem remains. How can I help you? Best, Dmitry

пт, 3 мая 2024 г. в 20:02, Oleksiy Yakovenko @.***>:

@eshchenko https://github.com/eshchenko can you try again with latest master -- commit #cbd5d9b more specifically? It's quite suspicious that only cue files stop working after the commit you referred to, which introduced the use of AC_SYS_LARGEFILE. If this fix doesn't help, I'll try to investigate more. It's problematic to revert, because in my understanding this would break musl builds. Potentially may require a special manually specified configure flag for musl users.

— Reply to this email directly, view it on GitHub https://github.com/DeaDBeeF-Player/deadbeef/issues/3070#issuecomment-2093509527, or unsubscribe https://github.com/notifications/unsubscribe-auth/AIZIW5WOQHIVW3OKKQQYLOTZAPGNFAVCNFSM6AAAAABFUEYSGGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJTGUYDSNJSG4 . You are receiving this because you were mentioned.Message ID: @.***>

[Oleksiy-Yakovenko]

I made another attempt -- basically keeping both AC_SYS_LARGEFILE, and using lseek64 in vfs_stdio. Please give it a try.

Other than that, I still can't see any obvious problem with the code. It would take some debugging on device to figure out what goes wrong.

[Oleksiy-Yakovenko]

It might help if you post your config.log after running ./configure

[eshchenko]

Dear Oleksiy

First of all - I found an error in the description of the problem: It i about the ape + .cue, not flac + .cue The cue.zip file was correct, it refers to the *.ape file (hope you opened it and already realized that the story is about ape, not flac). I am sorry for this typewriting error! The correct description of the problem is:

Compile deadbeef from fresh git on raspberry pi. From your the file manager (e.g. from the pcmanfm or from the file browser plugin) drag and drop a directory with ape and cue files into the "playlist with tabs" window. The result is: .cue file is not loaded - the palyer shows .ape file as a single track.

First I was thinking - maybe it is a problem with the file manager. But I can reproduce the problem using the native deadbeef tools: File/+Add folder(s).

It is interesting that I can open the .cue using File/Open file(s) The result is: the .ape file is loaded and all the tracks are shown according to the *cue.

What I also tried - rename the .cue (to change a possible loading order, if it is alphabetic), make an error in .cue (to force the errors) Nothing - it looks like the *.cue is ignored!

I had tried your last code suggestions - the result is the same - I still need to remove AC_SYS_LARGEFILE

Please find here attached two config.log files: config.log.zip The first file config.log_202405042000 is after the fresh git. This compilation produces *.cue error. The second file config.log_202405050039 is the fresh git after I commented the AC_SYS_LARGEFILE in the configure.ac. This player is good.

The configure parameters for these two builds are little bit different: the --prefix directories are different, also for the second compilation I disabled the gtk2 (I am forced to use gtk3 in any case).

Best, Dmitry

[Oleksiy-Yakovenko]

Thanks for the logs. From the logs, the only impression I could get is that AC_SYS_LARGEFILE is not really working on RPI system. Maybe it doesn't work with any 32 bit systems. Either way, I think that removing it would not do harm anymore, since I already added glibc ifdef, so the code should run fine on musl systems.

[Oleksiy-Yakovenko]

There's a downside of this change: on 32 bit systems which don't use glibc there would not be large file support. This will primarily affect more exotic systems. I hope to find a better fix in the future.