can't add tracks from finder

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.

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.

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
>

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

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

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?

@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.

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.

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

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().

Should we include this fix in 2.1.7?

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

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.