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 8fa263e
8fa263e 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 8fa263e
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 <#3070 (comment)>, 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.