Network error during upload via audio encoder

The audio encoder is currently producing a more or less random error when uploading some files – it aborts the upload process with a “Network error” but doesn’t output anything in the log.

Can anyone tell me what the problem might be?
Firefox produces time outs for the same files, while Chrome displays the aforementioned network error.

These files are no larger than some I’ve already successfully uploaded…
I therefore cannot understand why it produces this error.

Can you check the browsers dev mode output?

How many files are you trying to encode?

15 files, each between 50 and 90 MB in size.

I’ll have to check the browser, it might take a while (no idea and never done it before ^^).

Edit:
Dev Mode returns the following error. The third file was different from the previous one, and the remaining attempts all use the same files (The one that is marked as play above - that was the file started from Firefox, before the time out).
Is my RAM insufficient for this?! Then why did it work before, even with larger files? :thinking:

This is a limitation of your browser. You might google around what you can do to increase that. Some background:The mp3s are decoded into uncompressed pcm files on browsers end. That means they are a lot bigger than the mp3 version.

Another solution:You might upload the mp3 to teddycloud and then choose them in the library to decode into a taf, that might work as it’s completely done in backend in this way.

Hmm, okay, thanks for the insight.
I didn’t know you could upload without converting directly. I’ll give that a try.

The only question that remains is why it worked several times before and now doesn’t work anymore - I’ve already successfully uploaded 99 tracks with almost 10 hours of playback, which surprises me.

Then the hard drive storage could also be the problem, right? It’s actually running low from time to time, so maybe that’s the problem or the explanation for why it worked before…?

Thank you :slight_smile:

I am not a browser expert. Maybe it does not clean up correctly.

Try a restart if the browser.

It could be a difference if you try to decode a lot of smaller files or just a few big files. Don’t know.

The size of the individual tracks hasn’t played a role so far; I’ve successfully uploaded both: a few large tracks and many smaller ones, and vice versa. So it shouldn’t really make a difference.

Unfortunately neither helped - nor restarting the browser, nor clearing the cache, nor freeing up disk space.
Now the upload works but the encoding still fails. After clearing the cache of the browser, it now fails with the error message “Invalid protoLen=0, pos=0” on encoding the eighth of ten tracks.

Log from direct encoding error today:

INFO |handler_api.c:1871:taf_encode_start| [TAF]   new chapter for 008 - Benjamin Blümchen auf dem Baum.mp3
INFO |toniefile.c:0394:toniefile_new_chapter| new chapter at 0x0000B0B2
INFO |handler_api.c:2116:handleApiPcmUpload| [TAF] Ended encoding
INFO |mqtt.c:0690:mqtt_init_box| Skipping client 'Toniebox' (cn: 'default')
WARN |handler_rtnl.c:0113:handleRtnl| Invalid protoLen=0, pos=0
INFO |server.c:0931:server_init| 0 open HTTPS Web connections

What’s going wrong this time?

Unfortunately, uploading first and then encoding didn’t work either. First time, he did abort it while encoding, today he didn’t even start with the following error:

Teddy2

The Warning has nothing to do with the encoding. It’s rtnl. So something unrelated here.

Have you checked if the taf file is nevertheless created? It could be that the frontend lost connection to the backend and the error is misleading.

What hardware are you using for teddycloud?

I can not really support here now, as I am not at home for the next time.

In the above case, the taf file was created – but only up to episode 8 of 10, obviously.
In the below case, with the error message during the upload, it isn’t created; I’ve also had various error messages there. As long as they relate to the upload, the taf file has actually never been created.

The cloud is installed on a Ugreen NAS via Docker and Portainer. The connection is therefore only via the local LAN. So, I think a problem would be more likely to be on the PC side? NAS runs normal, as I can see.

Thanks for your effort :slight_smile:

A PC restart apparently solved the cache problem (I had forgotten that I had left the PC running for a few days due to something else - so it’s not so surprising that the caches were full). However, the other errors remain.

I still haven’t been able to identify the cause of the network error during conversion, but I have a solution that works for me at the moment:
I open the corresponding track where it gets stuck in mp3DirectCut and save it again unedited - after that it has always worked so far (after the cache problem was solved).

The reason is not clear to me, but at least it uploads without any problems.