Recently, destination has / replaced with #

[danwdart]

E.g.:

Downloading CsGYh8AacgY
/var/www/projectchaplin/application/../external/youtube-dl --prefer-free-formats -o '/var/www/projectchaplin/public/uploads/%(title)s.%(ext)s' -- "CsGYh8AacgY"
[youtube] Setting language
[youtube] CsGYh8AacgY: Downloading video webpage
[youtube] CsGYh8AacgY: Downloading video info webpage
[youtube] CsGYh8AacgY: Extracting video information
[download] Destination: #var#www#projectchaplin#public#uploads#Charlie the Unicorn.webm
[download] 100.0% of 5.67MiB at 11.32MiB/s ETA 00:00
Downloaded CsGYh8AacgY

Know what's going on here?
Cheers

[phihag]

Sorry, I cannot reproduce this problem - it all works fine on my machine. Can you add the --verbose option? That will output additional debugging information that should shed some light on what's going on.

[danwdart]

Not much more really.

Downloading QFCSXr6qnv4
/var/www/projectchaplin/application/../external/youtube-dl --verbose --prefer-free-formats -o '/var/www/projectchaplin/public/uploads/%(title)s.%(ext)s' -- "QFCSXr6qnv4"
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['--verbose', '--prefer-free-formats', '-o', '/var/www/projectchaplin/public/uploads/%(title)s.%(ext)s', '--', 'QFCSXr6qnv4']
[debug] youtube-dl version 2013.05.07
[debug] Python version 2.7.3 - Linux-3.2.0-4-amd64-x86_64-with-debian-7.0
[debug] Proxy map: {}
[youtube] Setting language
[youtube] QFCSXr6qnv4: Downloading video webpage
[youtube] QFCSXr6qnv4: Downloading video info webpage
[youtube] QFCSXr6qnv4: Extracting video information
[download] Destination: #var#www#projectchaplin#public#uploads#Charlie the Unicorn 2.webm
[download] 100.0% of 49.91MiB at 9.39MiB/s ETA 00:00
Downloaded QFCSXr6qnv4

[phihag]

Well, that showed that you're using the newest version. I have looked both into our history and the source code that formats file names, and both seem completely fine. The output Downloaded QFCSXr6qnv4 makes me think that you're using some kind of external additional script. Can you post that? What if you run youtube-dl without it?

Additionally, do you get the same output if you pass in --get-filename? What if you add a print in the prepare_filename function?

[danwdart]

yes - I'm using project chaplin's passthru:
https://github.com/dandart/projectchaplin/blob/master/library/Chaplin/Service/YouTube/API.php

So using the command on its own returned using the hashes again.

Using --get-filename works properly:
/var/www/projectchaplin/application/../external/youtube-dl --verbose --prefer-free-formats -o '/var/www/projectchaplin/public/uploads/%(title)s.%(ext)s' --get-filename -- "QFCSXr6qnv4"
[debug] System config: []
[debug] User config: []
[debug] Command-line args: ['--verbose', '--prefer-free-formats', '-o', '/var/www/projectchaplin/public/uploads/%(title)s.%(ext)s', '--get-filename', '--', 'QFCSXr6qnv4']
/var/www/projectchaplin/public/uploads/Charlie the Unicorn 2.webm

Adding the print strangely doesn't produce anything different (unless there are some steps to recompile the script?)

[phihag]

I see you're using a git submodule. That's fine, but to run the checked out source code, you should just call youtube-dl with

python -m youtube_dl

Alternatively, type make to compile youtube-dl to a single binary.

This looks extremely weird, after printing the file name we just encode it to UTF-8 (or whatever encoding you use), and that should never lead to the outcome you're seeing. Can you reproduce the problem with

wget http://youtube-dl.org/downloads/2013.05.10/youtube-dl -O youtube-dl
chmod a+x youtube-dl 
./youtube-dl -v --prefer-free-formats -o '/var/www/projectchaplin/public/uploads/%(title)s.%(ext)s'  -- QFCSXr6qnv4

? If yes, we have to dig deeper into your configuration. If no, then there's a difference in how you call youtube-dl.

[danwdart]

So calling using python -m:

(print):
/var/www/projectchaplin/public/uploads/Charlie the Unicorn 2.webm
(dest):
[download] Destination: #var#www#projectchaplin#public#uploads#Charlie the Unicorn 2.webm

and using the wget'd version:
[download] Destination: #var#www#projectchaplin#public#uploads#Charlie the Unicorn 2.webm
again.

[phihag]

That's really strange; I cannot reproduce it on any of my systems. Can you reproduce it on the system you reach with

ssh dandart@ytdl-dandart.phihag.de

That should be a debian squeeze. Feel free to modify the system as you like, like you do with yours. Alternatively, feel free to give me ssh access to a demo system of yours.

[phihag]

@dandart ping, can you reproduce the issue on the VM? As I said, I'm almost certain that something else is wrong here.

[danwdart]

Sorry, currently in the process of moving. Difficult to connect to on my internet... trying hardest...

[danwdart]

Yes, my pipes keep breaking.

[phihag]

@dandart Can you reproduce this on ytdl-dandart.phihag.de ? As far as I can see in the history, you just installed screen and locales. On that machine,

./youtube-dl -v --prefer-free-formats -o '/home/dandart/var/www/projectchaplin/public/uploads/%(title)s.%(ext)s'  -- QFCSXr6qnv4

works as expected for me.

[danwdart]

All I was going to do was set locale to en_GB ... The server I must be
using must have a weird utf-8 implementation, is that all it could be?

[phihag]

Oh, I'm very sorry, should've seen in right away: This is some win32 compatibility code (which we cannot special-case for sys.platform since the drive could be remote) in effect. It should be fixed in youtube-dl 2013.05.13, which will be released shortly.

Note that the original error is caused by something else; most likely because the directory
/var/www/projectchaplin/public/uploads/ is not writable. Check its permissions and use chown/chmod to allow the user running youtube-dl to create the downloaded file in there.

[danwdart]

Heh. That compat code did fix it thanks.
I don't remember having any error to do with writing permissions other than the obvious "can't write"...