get_iplayer forums

HI

I have an odd problem that I just can't seem to resolve.

I use the raspberry pi version of GIP and have 2 zyxel servers (nsa325 and nas540) to download to.

Both servers have the same fstab entries (bar ip address) and mount OK with read and write. But when I select download with --mkv, it works on the nsa325, but the exact same command for the nas540 always fails with unsupported video codec.

I have tried this on 4 different reapberry pi and always the same problem. It is repeatable too in that starting the download again always crashes out at the same point.

How can it download and convert on one smb mounted server and fail on another?
Where are the log files?

Any help to my confusion would be most welcome :)

Read this and fill in the gaps in your report:

thread-706.html

I do apologise!

Version gip = 2.94-ppa23
version = raspberry pi (running xbian OS) with kernel 4.4.8 (happend also with previoius kernels)

So when I do this to download and convert to the NAS540 it fails as shown.

Code:
xbian@kitchen ~ $ get_iplayer --get --pid=b04gvnfv --modes=best --whitespace --nopurge --file-prefix="<nameshort>-<senum>-<episodeshort>" --mkv --output /mnt/540/ --force

get_iplayer 2.94-ppa23, Copyright (C) 2008-2010 Phil Lewis

 This program comes with ABSOLUTELY NO WARRANTY; for details use --warranty.

 This is free software, and you are welcome to redistribute it under certain

 conditions; use --conditions for details.

INFO Trying to stream pid using type tv

INFO: pid found in cache

Matches:

849:    Our School: Series 1 - We Are Year 7, CBBC, , default

INFO: 1 Matching Programmes

INFO: Checking existence of default version

INFO: flashhd1,flashvhigh1,flashvhigh2,flashhigh1,flashhigh2,flashstd1,flashstd2,flashlow1,flashlow2 modes will be tried for version default

INFO: Trying flashhd1 mode to record tv: Our School: Series 1 - 1. We Are Year 7

INFO: File name prefix = Our School-s01e01-We Are Year 7

RTMPDump v2.4-n78-git3a1e20c-ppa8~wheezy

(c) 2010 Andrej Stepanchuk, Howard Chu, The Flvstreamer Team; license: GPL

Connecting ...

INFO: Connected...

Starting download at: 0.000 kB

INFO: Metadata:

INFO:   duration              1700.04

INFO:   moovPosition          36.00

INFO:   width                 1280.00

INFO:   height                720.00

INFO:   videocodecid          avc1

INFO:   audiocodecid          mp4a

INFO:   avcprofile            100.00

INFO:   avclevel              41.00

INFO:   aacaot                2.00

INFO:   videoframerate        25.00

INFO:   audiosamplerate       48000.00

INFO:   audiochannels         2.00

INFO: trackinfo:

INFO:   length                42501000.00

INFO:   timescale             25000.00

INFO:   language              und

INFO: sampledescription:

INFO:   sampletype            avc1

INFO:   length                81601536.00

INFO:   timescale             48000.00

INFO:   language              und

INFO: sampledescription:

INFO:   sampletype            mp4a

494677.196 kB / 1700.01 sec (99.9%)

Download complete

avconv version 11.6-6:11.6-1~deb8u1+rpi1, Copyright (c) 2000-2014 the Libav developers

 built on Mar 22 2016 15:53:22 with gcc 4.9.2 (Raspbian 4.9.2-10)

[flv @ 0x1007200] max_analyze_duration 5000000 reached

Input #0, flv, from '/mnt/540/Our School-s01e01-We Are Year 7.partial.mkv.flv':

 Metadata:

   moovPosition    : 36

   avcprofile      : 100

   avclevel        : 41

   aacaot          : 2

   videoframerate  : 25

   audiochannels   : 2

   length          : 81601536

   timescale       : 48000

   sampletype      : mp4a

 Duration: 00:28:20.04, start: 0.000000, bitrate: N/A

   Stream #0.0: Video: h264 (High), yuv420p, 1280x720 [PAR 1:1 DAR 16:9], 25 fps, 1k tbn, 50 tbc

   Stream #0.1: Audio: aac, 48000 Hz, stereo, fltp

[matroska @ 0x1008e80] Codec for stream 0 does not use global headers but container format requires global headers

[matroska @ 0x1008e80] Codec for stream 1 does not use global headers but container format requires global headers

Output #0, matroska, to '/mnt/540/Our School-s01e01-We Are Year 7.partial.mkv':

 Metadata:

   moovPosition    : 36

   avcprofile      : 100

   avclevel        : 41

   aacaot          : 2

   videoframerate  : 25

   audiochannels   : 2

   length          : 81601536

   timescale       : 48000

   sampletype      : mp4a

   encoder         : Lavf56.1.0

   Stream #0.0: Video: libx264, yuv420p, 1280x720 [PAR 1:1 DAR 16:9], q=2-31, 1k tbn, 1k tbc

   Stream #0.1: Audio: aac, 48000 Hz, stereo

Stream mapping:

 Stream #0:0 -> #0:0 (copy)

 Stream #0:1 -> #0:1 (copy)

Press ctrl-c to stop encoding

[flv @ 0x1007200] Unsupported video codec (8)

frame=  148 fps= 38 q=-1.0 Lsize=    1852kB time=5.88 bitrate=2579.9kbits/s

video:1780kB audio:68kB other streams:0kB global headers:0kB muxing overhead: 0.212185%

INFO: Recorded /mnt/540/Our School-s01e01-We Are Year 7.mkv

But if I issue the same command to save on the nsa325 server it works every time! -
The error suggests avconv is missing a codec, but why/how can it work on the 325 and not the 540? If the pi was missing a codec it would surely fail on both, no?
What am I not getting here?

(04-05-2016, 04:56 PM)But if I issue the same command to save on the nsa325 server it works every time! -
The error suggests avconv is missing a codec, but why/how can it work on the 325 and not the 540?

No way even to guess until you post the output from the command that works when downloading to 325. There may be nothing useful there, but we can't know until we see it.

Other things to look at:

Try a different programme to see if the same problem occurs. Use something small like an episode of Weather for the Week Ahead.
Try to play the .flv file left behind on 540. If it won't play, it may be getting corrupted such that re-muxing also fails. The error appears to come in decoding of the .flv file
Try to re-mux the .flv file outside of get_iplayer:
avconv -i file.flv -c:a copy -c:v copy -y file.mkv
Try downloading with --modes=flashhigh to see if the problem is unique to HD version
Try downloading with --modes=hlsbest to see if the problem is unique to Flash format

No need to post output from any of those.

(04-05-2016, 07:06 PM)No way even to guess until you post the output from the command that works when downloading to 325. There may be nothing useful there, but we can't know until we see it.

Where do I find 'the output from the command that works'? I have looked in /etc and /.getiplayer and nothing there! - The web site about posting suggests a link to this info, but there is nothing there for me using firefox latest...

Try a different programme to see if the same problem occurs. Use something small like an episode of Weather for the Week Ahead.

It happens on all programs I have tried for months now. Believe me this is my last resort coming on here as I really hit the end of the testing line with my knowledge!

Try to play the .flv file left behind on 540. If it won't play, it may be getting corrupted such that re-muxing also fails. The error appears to come in decoding of the .flv file

There is no flv file left behind as it gets deleted once it thinks the mkv is done.

Try to re-mux the .flv file outside of get_iplayer:
avconv -i file.flv -c:a copy -c:v copy -y file.mkv

See above. But I can d/l without the --mkv and then try that, would that help?

Try downloading with --modes=flashhigh to see if the problem is unique to HD version

Try downloading with --modes=hlsbest to see if the problem is unique to Flash format

That I will try tomorrow. the download command line is the same for both, just that /mnt/325 is changed for /mnt/540 to map to the other server. This obviously works as it downloads fully and tires to mkv it.

Thanks for the suggestions, maybe we will get to the bottom of this one yet! ;)

Guess I don't understand how quotes work on here either ;)

Just did a test to get without --mkv and the file downloads fully, but then gets converted to mp4 even nothing in the command asked for this! - I also did --prefs-clear and tried again (without rebooting if that makes a difference) and still the same.

I have to say the quality was rather pixellated on the image with what I can only describe as transparency and latency in the image. Does that make sense?

(04-05-2016, 08:55 PM)Where do I find 'the output from the command that works'?

The same way you got the output for the command that didn't work, which you posted earlier

(04-05-2016, 08:55 PM)There is no flv file left behind as it gets deleted once it thinks the mkv is done.

In that case, download with --raw, which will retain the FLV file and prevent re-muxing to MP4

(04-05-2016, 08:55 PM)That I will try tomorrow. the download command line is the same for both, just that /mnt/325 is changed for /mnt/540 to map to the other server. This obviously works as it downloads fully and tires to mkv it.

Again, seeing is believing, so post the output from a successful download.

(04-05-2016, 09:12 PM)Just did a test to get without --mkv and the file downloads fully, but then gets converted to mp4 even nothing in the command asked for this!

That is the default behaviour

(04-05-2016, 09:12 PM)I have to say the quality was rather pixellated on the image with what I can only describe as transparency and latency in the image. Does that make sense?

There is no way to answer that without having the file, though I suspect those are playback problems rather than any intrinsic problems with the file, unless your machine is too underpowered or avconv is butchering the video.

Just done a quick test....

D/l to the 540 using --raw gives a good flv file with no image quality issues.

Then converting with avconv to mkv manually (as you posted above) gives a full mkv file of expected size, but has the quality issues.

The output you want disappears from the box (I use putty to talk to the pi) and it only holds so much data. After a while the mkv conversion starts adding lines every second or more and so scrolls the start off the screen. Is this output available in a log file somewhere?

Cheers, you have helped me to get a handle on this now! :)

(04-05-2016, 11:02 PM)Then converting with avconv to mkv manually (as you posted above) gives a full mkv file of expected size, but has the quality issues.

When re-muxing, ffmpeg is reading the entire file off the NAS, processing it in system memory and then writing it all back to the same disk in a different container format. You have an underpowered machine and possibly a slow network disk, which can cause glitches and failures (though I've never seen your original error in such circumstances). Although I gave up on it long ago, I know some people get by OK with get_iplayer on RPi, so that suggests your 540 could be the issue. Yours is not a general problem, so the underlying cause must lie somewhere in your particular setup. Perhaps you can configure your get_iplayer output directory on a SD card to see if that helps, and then copy the final files to 540 outside get_iplayer. And of course you could do the same thing with the 325.

(04-05-2016, 11:02 PM)The output you want disappears from the box (I use putty to talk to the pi) and it only holds so much data. After a while the mkv conversion starts adding lines every second or more and so scrolls the start off the screen. Is this output available in a log file somewhere?

Redirect standard output and error streams to a file as with any other command-line utility. If you don't know how to do that, Google is your friend.

There isn't anything more I can tell you on this. Perhaps a RPi user with better first-hand experience will happen by. Good luck.

I believe that it might be caused by scrimping on the HDD usedin the 540 as this time I went for Seagate NAS instead of WD reds.

It's the only thing that's different and I have no way to confirm this, but it looks most likely.

Darn it!

Anyone got some 6TB WD reds they would like to donate to a good cause? :)

These forums are archived

See this post for further info

Forum archived. Posting disabled.

Odd problem, raspberry pi and 2 servers.....

user-359

user-2

user-359

user-2

user-359

user-359

user-2

user-359

user-2

user-359

These forums are archived

See this post for further info