Unresponsive after Fixing malformed AAC bitstream with qtube

J

Jeddy

Member
Hi,
I have tried to download The_Ghan_-_Australia_s_Greatest_Train_Journey using qtube a couple of times. Each time it downloads 100% and then issues the message
14/01/2022 22:27:32 - [ffmpeg] Fixing malformed AAC bitstream in "/mnt/hd2/My Video/The_Ghan_-_Australia_s_Greatest_Train_Journey.mp4"
after which the remote and web interface become unresponsive. I have to turn the power off for the remote and interface to become responsive. However it then seems to keep booting itself up and doing the same thing. The only bypass I found for this was to remove qtube.
To give an idea, the above message was yesterday eve and 12+ hours later the box is stil unresponsive

Curiously I also tried playing the same prog via iplayer and saving the stream. While this appeared to work, fast forwarding to the end suggests that all is not well.

I know this is a long prg (3hrs), but am not sure if there is a problem with qtube or if the Beeb have done something to prevent downloading?

Before I reboot is there anything I should try (not too technical please)

Thanks,
Jeddy
 
Jeddy said:
Each time it downloads 100% and then issues the message...
Click to expand...
That's normal, I think you'll find this happens every time you use qtube/youtube-dl, and can't be blamed for your specific problem.

Jeddy said:
Curiously I also tried playing the same prog via iplayer and saving the stream. While this appeared to work, fast forwarding to the end suggests that all is not well.
Click to expand...
The "save last streamed content" button doesn't know how large the complete download should be, it only shows you that the buffer has stopped growing. If you terminate early (or the stream crashes), it won't be complete.

Jeddy said:
I know this is a long prg (3hrs), but am not sure if there is a problem with qtube or if the Beeb have done something to prevent downloading?
Click to expand...
I don't know, but the larger the download the more opportunity there is for the HDR-FOX to bork. However, that the youtube-dl operation got as far as trying to fix the stream implies it thinks it downloaded all the packets.

Jeddy said:
Before I reboot is there anything I should try (not too technical please)
Click to expand...
I doubt it. I would have rebooted pretty soon and put it down to "just one of those things".
 
I agree that the initial message is normal, however normally it sorts itself out. This time the box effectively freezes - which I'd suggest isn't normal? Also the fact that I've now downloaded this program twice and the same thing has happened twice suggests it is more than just one of those things. Also that it effectively breaks qtube isn't normal - otherwise I'd have had to remove and add qtube every time I downloaded a program - which obviously I haven't - it's mostly worked fine in the past.
 
For info, having rebooted the web interface shows it is 'playing' the program with the green play icon. I suspect that is nothing more than an indication it is trying to fix the bitstream.
 
All that means is the file is open for reading. Check WebIF >> Diagnostics >> Queued Tasks to see what's happening (if anything).

Maybe the swap space needs increasing. I suppose there's no possibility the swap is disabled?
 
Well, if you read the swapper thread you would see that free -m provides stats for "mem" and "swap", so if "swap" isn't listed or shows 0 you will know you don't have any swap space.

The swapper package sets up swap space each boot (128MB), but equally the swapper thread demonstrates how to set up a 128MB swap manually, which can be adapted to to 256MB or whatever you like (but needs turning on again after boot). So, to make it double (I guess that will be enough, considering the crash is near the end of the processing):
Code: 
swapoff /mnt/hd3/.swap0
rm /mnt/hd3/.swap0
dd if=/dev/zero of=/mnt/hd3/.swap0 bs=1M count=256
mkswap /mnt/hd3/.swap0
swapon /mnt/hd3/.swap0

Google "linux help dd" for dd command explanation (like wot I just did), and you'll see that:
  • "if" means "Input File", so "=/dev/zero" means it is just sourcing a string of zero bytes;
  • "of" means "Output File", creating the .swap0 file;
  • "bs" is the number of bytes in a block;
  • "count" is the number of blocks
...in other words, it creates a 256MB empty .swap0 file on hd3 by copying that many bytes across from a null source.

The rm... command might not be strictly necessary, but I preferred to start with a clean slate.
 
Last edited:
:oops:

Brain fade. I've always said authors need proof-readers, and this proves the point (authors see what they think they wrote, the mind presumes it is correct). Patching up...

I also couldn't find a way to copy&paste webshell output (WIn7/Chrome), which rather frustrated what I was doing (I would have published the terminal dialogue otherwise).
 
Last edited:
I've repeated the exercise on another HDR and confirmed the findings. Can't copy&paste from iOS/Safari either. I have also confirmed I did in fact install a 512MB swap file on the first HDR.

Now we just await @Jeddy to confirm whether an enhanced swap space solves his problem.
 
Thanks for that! I did actually look at the swapper link, but it quickly became apparent that the knowledge assumed was beyond my current level which as I hopefully implied in my initial post 'not too technical please', isn't great. I'm guessing the humax# references are some form of console prompt? I'm sure there are instructions somewhere how to use that if so. Or do I need to edit a file - (I note I have a file editor under diagnostics, although I don't think I've ever played with it).

If you can point me in the right direction without this getting horribly complicated I don't mind testing (fortunately I have unlimited downloads - just as well as this file is over 6Gb each time and I've already downloaded 2 or 3 times in the last week).

The better news is that I eventually managed to get onto the web interface after rebooting and before it hung and first hold and then delete the queued item (previous attempts had failed to either hold or delete it). That seems to have fixed the repeated restarting of the box and quickly hanging - I had to turn the box on this a.m. rather than it finding it had once again started overnight and again trying to 'play' the offending file.
I also managed to use iplayer to play the program and save the stream which is slightly larger than last time (2.19Gb rather than 1.7Gb). It appears that last time the box trying to correct the initial file may have stopped it fully downloading the iplayer file, once that problem was sorted the saving of the complete stream seems to have worked and I was able to play snippets including the end on my PC.
I'm not sure why the .mp4 from iplayer is 2.19Gb while the .mp4 which qtube downloaded was over 6Gb! It suggests a difference in quality?

As I say, if you can help, I don't mind testing the fix if you are considering making the change permanent in qtube, but I hopefully have what I wanted.

Thanks,
Jeddy
 
Jeddy said:
I'm guessing the humax# references are some form of console prompt?
Click to expand...
Yes:
  1. Install webshell and reboot
  2. WebIF >> Diagnostics >> Command Line
  3. PIN = 0000 (unless you've changed it)
  4. Type "cli" (Command Line Interface selection from the menu) and Return
  5. Enter the commands exactly as shown in post 9 to increase the swap space from 128MB (swapper default) to 256MB
  6. "exit" to exit the webshell session.
More info: Command Line FAQ
 
Thanks, I don't suppose there is an option to paste copied text is there (avoid any accidentaly typos etc..)? Ctl-V doesn't seem to work (yeah, I know, it's not windows)
 
Paste where or in/with what? You can copy/paste in Webshell, and in any telnet client I've ever come across.
 
Misc 2p-worth:
  • if you get the browser's own right-click menu overlaying the Webshell context menu, ESC may clear it;
  • an invalid .mp4 can cause the set-top UI to hang;
  • you can control the size of your iPlayer download with qtube by specifying a youtube-dl format selector.

The iPlayer saved stream will reflect the bit-rate that the iPlayer app thought was appropriate to play in real time. Although in principle you can ask for [tbr<=1500] to get a file of similar size to the saved stream download, it's always a bit of a guess as to whether the total bit-rate, or the video bit-rate (vbr), or neither, are actually supported for a particular extractor, but the BBC extractor should support at least one. In the neither case, height can be used as a proxy.
 
Thanks, I should have worked out right click myself! Apologies - you know how it is when you're going somewhere you don't understand, I'm frighhtened by everything! Anyway... hopefully this has worked. I see it says it is setting up swap space around 256MB which sounds hopeful.


1642339446397.png
 
You must log in or register to reply here.
Back
Top