can't add tracks from finder

[Jehyun Yoon]

* Operating system (Windows, Linux, OSX, etc.) and version
macOS Sierra 10.12.6
* CPU architecture (Athlon, Core 2 Duo, Celeron, Pentium II, etc.) and speed (in MHz or GHz)
Core i5 @ 1.7Ghz
* Your video and sound hardware (Brands, models, options, etc.)
* Steps to reproduce the problem
upgrade mixxx from 2.0 to 2.1
* Information logs
after I upgrade mixxx 2.0 to 2.1
I cannot adding my files with file drag-and-drops from finder
but after I replace 2.1 to 2.0 again, It works well
and when I upgrade to 2.1 Library has disappered and I change to Tracks
but after I replace 2.1 to 2.0 again, Library has appeared again

[Daniel Schürmann (daschuer)]

Cane other mac users confirm this?

Is there something suspicious in the mixxx.log file?
https://mixxx.org/wiki/doku.php/finding_the_mixxx.log_file

Please try again to drop a track and attach the mixxx.log file here.

[Be (be.ing)]

I am removing this from the 2.2.0 milestone considering the original reporter has not responded in months and no one has been able to reproduce this.

[Jehyun Yoon (sicriops)]

I'm sorry for soooo late reply
This issue is still occured in build 2.1-r6765
So, I'll send you mixxx.log with --logLevel trace option
I hope it'll clear this issue soon

regards,
Jehyun

2018년 9월 11일 (화) 오전 10:11, Be <email address hidden>님이 작성:

> I am removing this from the 2.2.0 milestone considering the original
> reporter has not responded in months and no one has been able to
> reproduce this.
>
> ** Changed in: mixxx
> Milestone: 2.2.0 => None
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1776949
>
> Title:
> can't add tracks from finder
>
> Status in Mixxx:
> New
>
> Bug description:
> * Operating system (Windows, Linux, OSX, etc.) and version
> macOS Sierra 10.12.6
> * CPU architecture (Athlon, Core 2 Duo, Celeron, Pentium II, etc.) and
> speed (in MHz or GHz)
> Core i5 @ 1.7Ghz
> * Your video and sound hardware (Brands, models, options, etc.)
> * Steps to reproduce the problem
> upgrade mixxx from 2.0 to 2.1
> * Information logs
> after I upgrade mixxx 2.0 to 2.1
> I cannot adding my files with file drag-and-drops from finder
> but after I replace 2.1 to 2.0 again, It works well
> and when I upgrade to 2.1 Library has disappered and I change to Tracks
> but after I replace 2.1 to 2.0 again, Library has appeared again
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1776949/+subscriptions
>

[RJ Skerry-Ryan (rryan)]

What kind of files are you dropping from the Finder? Are they always files Mixxx supports?

[RJ Skerry-Ryan (rryan)]

@daschuer -- did you mean to add the qt4 tag? this is on 2.1?

[Daniel Schürmann (daschuer)]

Oh yes, it must be too late when tagging this bug.

I have recently read that we need to use http://doc.qt.io/qt-5/qfile.html#decodeName

Instead of just toLocal8bit on Mac, because Mac uses the decomposed version of file names in it's char API. Could this be an issue here?

[Daniel Schürmann (daschuer)]

@Jehyun Yoon Unfortunatley there is no attempt to drop a file tracked in the attached mixxx.log file. Please start Mixxx, drop a file that fails, close Mixxx and attach the mixxx.log file again.

I assume there is a character encoding issue. In Mac we cannot just use toLocal8bit for file names, we need to use QFile::encodeName() which defaults to toLocal8bit() for our other targets.

[Daniel Schürmann (daschuer)]

Here some detail:
https://stackoverflow.com/questions/6153345/different-utf8-encoding-in-filenames-os-x
I am unsure where to put QFile::encodeName()
I think we need some tests first, if there is really an issue.
Who is able to verify, which Umlaut tracks can be dropped with which soundsource.

[Daniel Schürmann (daschuer)]

An effected forums user:
https://www.mixxx.org/forums/viewtopic.php?f=1&t=12335&p=40494

[Uwe Klotz (uklotzde-deactivatedaccount)]

QFile::encode/decodeName() includes some special case handling for macOS -> fully decomposed form!

We need to replace all file name conversions that use QString::to/fromLocal8Bit() to QFile::encode/decodeName().

[Uwe Klotz (uklotzde-deactivatedaccount)]

Should we include this fix in 2.1.7?

[Uwe Klotz (uklotzde-deactivatedaccount)]

I'm unsure if Sandbox::keyForCanonicalPath() is affected, too?

[Daniel Schürmann (daschuer)]

This problem is partly solved in 2.1.

Dorpping from finder is was reported as working after changing the skin.
Which is still an unwanted behavior.
So I have cloned this bug to 2.2 to not forget about this.