Problem with dailymotion.groovy

Hi,

I have a problem with dailymotion.groovy.

Some videos don't show in the "Online" folder, other do and play perfectly.
Here's my rss feed : http://www.dailymotion.com/rss/user/Mediapart/1
and I've attached the Serviio log file and a detailed debug log of a file that's not showing in the "Online" folder.
Let me know if you need additional information.

Thanks for your help,
Jérôme

[zip]

It looks like it could not connect to the file in 30 seconds and then given up.

Well, I downloaded the file and it show in the local movie folder and play fine.
But it is huge : 2+ Gb.
Could my problem be file size related ?
I have no network problem that could cause a timeout and even if it was the case it wouldn't be always on the same file...

[zip]

Might be the size, not sure how much of the file FFmpeg needs to read to get the media information

I too have no idea.
I've tested this on another machine (Linux Debian Unstable) with the exact same result (my first test was on Win 7 Home Premium).
It really seems to me that it's size related as it works perfectly with smaller files.
The question now is how to debug that.

[zip]

enable detailed log, try to play the file. Then quickly find the url of the file in the log and try to run

ffmpeg -i "url"

You have to do it quickly, because the URL will expire soon and you'd get 403 error

Output of ffmpeg - i.txt

(1.77 KiB) Downloaded 525 times

It was not easy but here it is.
I don't see no reason why it fails to play, though.

[zip]

Ok, I see why - there is a small bug in 1.2.1 with when there is a 'video' text anywhere above the video track in ffmpeg -i, it won't detect the video data properly. In this case there is 'video' in the URL, so that's why it fails.

It'll be fixed in 1.3 (which is a long way off still).

Well except that this one is working
http://www.dailymotion.com/cdn/H264-512 ... f0dc043443
see attached log.

And as you said it was caused by a bug in 1.2.1 I tested with 1.0.1 and the problem is there too.

So let me understand this...

You all are saying because there exists text such as advertising in a video, 1.2.1 just bugs out entirely in the transcoding of a Dailymotion video?

How is that possible... Shouldn't that not matter since the text is now encoded as part of the video stream and not as a seperate element of the video (this is quite fascinating)?

[zip]

no, not text inside a video, it's a bug in parsing the FFmpeg -i information

I don't understand...
The difference inside the log of ffmpeg -i from the working stream and the other is the file name and the bitrate.
And both files have the word "video" in their url...

[zip]

I'm now getting Forbidden on both the links, do you have an up-to-date version for me to re-test?

Hum, an up-to-date version of what ?

[zip]

the URLs for not working strem

Ok Petr...

For me, some streams work... My own personal one does not

http://dailymotion.com/rss/user/tstrike34/1

*scratches head*

Ok Petr...

For me, some streams work... My own personal one does not

http://dailymotion.com/rss/user/tstrike34/1

*scratches head*

Ya, this is very bizzaro... One would think that the type of video and encoding from the source (Dailymotion) would be fairly consistent (with the exceptions of the format given low, medium, and high qualities)

This is the rss feed of the non working video : http://www.dailymotion.com/rss/video/xyrx4v
Of course you won't see it inside Serviio.
And a working one : http://www.dailymotion.com/rss/video/xyrzqs/
(I've not found how to create a single request for 2 different video_id)

Ok Petr...

For me, some streams work... My own personal one does not

http://dailymotion.com/rss/user/tstrike34/1

*scratches head*

I'm confused : when I search on DM with your user id (tstrike34)
I get
Résultats de recherche pour tstrike34
"Woops! Pas de vidéos disponibles pour cette recherche. "
(Search results for tstrike34
No videos available for this search)

Ya, this is very bizzaro... One would think that the type of video and encoding from the source (Dailymotion) would be fairly consistent (with the exceptions of the format given low, medium, and high qualities)

It is consistent.
To summarize the problem, if we look at the output of ffmeg -i the only differences are the file name and the video bitrate (358 kb/s versus 359 kb/s).
The non working stream plays fine when downloaded and played in local.
Both streams have "video" in their url and the problem exists with 1.0.1 too
The only thingI've noted is that the non working stream is more than 2Gb but I have no idea if it is related.