m3u doesn't work in yaml "source" about deefuzzer HOT 23 CLOSED

Can you post the complete config file, as well as the contents of the m3u file you're referencing?

from deefuzzer.

OK I'll do that tonight ;-)

from deefuzzer.

@achbed My files: https://gist.github.com/ChoiZ/dcf97cc962a678b112c3

M3U playlist was generated by: https://github.com/ChoiZ/simple-php-scheduler or https://github.com/ChoiZ/simple-python-scheduler (I don't remember I think I use PHP, so it's the same code: one in PHP the other in Python).

from deefuzzer.

2015-01-30 00:45:28,852 INFO Station http://mystation/test.mp3: Generating new playlist (0 tracks)

The log entry says there's 0 tracks. This tells us that the M3U file is either not pointing to the files correctly, or all the files listed in the M3U do not exist.

Are your MP3s really at the root level (/mp3/*) or are they in a subfolder where the M3U file is located (ie, /some/path/to/m3u/mp3/*)? By the M3U standard, if the path in the file starts with a slash (or drive letter on Windows) then it's an absolute path, otherwise it's a partial path starting from the location of the M3U. 0.7 now adheres to the standard instead of attempting to find the files, and if the file is not found it doesn't add it to the playlist. So if you are dealing with a subfolder, you should remove the starting slash from all paths in the M3U file.

from deefuzzer.

Hrm - I wonder if the code is properly stripping off line endings or if it's trying to find /mp3/mp3-file.mp3\n instead of /mp3/mp3-file.mp3. Worth looking at. (Update: according to 0.7 codebase, we are using .strip() on the line which should take care of this)

from deefuzzer.

Hi achbed, I think my m3u file is correct (It's works with previous version of deefuzzer 0.6.6).
In my m3u I use path begin the root path (I'm on linux).
If I've got an m3u located in: /home/choiz/ and my song in /home/choiz/mp3/test.mp3 in my m3u I have to write /home/choiz/mp3/test.mp3 or directly mp3/test.mp3 ?

from deefuzzer.

Maybe with .rstrip() ?
http://stackoverflow.com/questions/275018/how-can-i-remove-chomp-a-newline-in-python

from deefuzzer.

Either one should work according to the standard. I'll whip up a test and see what I can find.

from deefuzzer.

.strip() removes white space from both the beginning and end of the string, where .rstrip() only strips white space from the end. So our using .strip() in the code should be sufficient.

from deefuzzer.

Ok I add 2 print in the code: deefuzzer/station.py, one before and one after: fp = self._path_m3u_rel(path)
It's display the first but doesn't display my second print. Can helps you?

from deefuzzer.

Seems working well. Generating new playlist (802 tracks).

I replace:

def _path_m3u_rel(self, a):
    return os.path.join(os.path.dirname(self.source), a)

By:

def _path_m3u_rel(self, a):
    return a

from deefuzzer.

That breaks standards but works if the full path is in the m3u. I'll take a
closer look at that function.
On Jan 30, 2015 2:54 PM, "François LASSERRE" [email protected]
wrote:

Seems working well. Generating new playlist (802 tracks).

I replace:

def _path_m3u_rel(self, a):
return os.path.join(os.path.dirname(self.source), a)

By:

def _path_m3u_rel(self, a):
return a

—
Reply to this email directly or view it on GitHub
#67 (comment).

from deefuzzer.

Oh ok I think m3u must have only absolute path. Nice point. 👍

from deefuzzer.

 def _path_m3u_rel(self, a):
    return os.path.join(os.path.dirname(self.source), a)

it's not source but media_source no?

from deefuzzer.

facepalm Yes that is indeed the problem. To prevent similar issues/confusion in the future, I'm going to refactor and use self.source everywhere instead of self.media_source. Any objections?

from deefuzzer.

Not for me ;) I made the pull request #70

from deefuzzer.

no more self.source in deefuzzer/station.py

from deefuzzer.

Did you commit your changes anywhere? Or should I submit the pull request?

from deefuzzer.

I send PR #70 and add another one for trailing whitespaces.

from deefuzzer.

Yes absolute paths are really needed for M3U. Well done!

from deefuzzer.

Do you have a link to the M3U file definition? I had been using the one on Wikipedia at https://en.wikipedia.org/wiki/M3U - and it clearly stated that both full paths and relative paths are allowed. If there's a better source, I'd like to reference it.

from deefuzzer.

No better source, but allowing relative paths in the case of deefuzzer is dangerous I think because an instance of deefuzzer can be started from anywhere and the config file not always in the media root.
Maybe I can miss some possibilities offered by your refactoring, but I tend to think this restriction in our case could prevent us from many issues..

from deefuzzer.

Given that the relative path is relative to the M3U file, not an arbitrary base_directory parameter in the config, we are probably limiting the security impact. We can probably eliminate most of the attacks completely if we then check for file type before adding them to the playlist.

We should probably invest in a complete security review though, rather than attacking these issues piecemeal.

from deefuzzer.