Hi there,
will it be possible to run ReadyMedia, or what it´s still called in OpenWRT minidlna on OpenWRT so that it will be acutal usable some time soon?
In the moment it keeps hanging when scanning even small libraries with just a few thousand songs because of the low RAM you have on routers´s. So in fact it´s not usable at all for the OpenWRT community and peopole using it.
So my question is, will it change sometime? Will there be a config option or some improvements in the code that will make it possible to run it with very very low RAM?
It would be really nice, cause this is the one and only DLNA program in OpenWRT and it´s completely broken.
Thanks in advance!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
it already has 64MB of RAM though. It´s not one of this real tiny devices, it has quite some power. I don´t know if the SWAP thing can help me because i noticed that not the whole RAM is used during the scan of minidlna, actually there is "plenty" of free RAM when it stocks.
Anyone? The developer itself maybe? I can run tests and so on if it helps you out somehow.
Last edit: Alternativend 2016-04-19
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use openwrt and minidlna on a netgear router with 64 megs just fine. Occasionally, I come across a file that causes OOM. Removing the file or rewriting the container is an easy workaround.
ssh into your router and run minidlna in debug mode using '-d -R' options to find out what is happening.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have removed a few video files which were in the root directory of the usb hard disk, which should not be scanned. After doing this minidlna scans about 13,000 files instead of 1,000 before. After these 13,000 he hangs as before. A complete scan should find about 30,000 files on the disk.
Im posting this here and in the OpenWRT forum, cause i don´t know who can help me.
Greetings!
Edit:
And have a look at this:
# /etc/init.d/minidlna start
root@OpenWrt:/mnt/usb# ps | grep minidlna
3002 root 10304 S /usr/bin/minidlna -f /tmp/minidlna.conf
3005 root 55072 D N /usr/bin/minidlna -f /tmp/minidlna.conf
3015 root 1496 S grep minidlna
Is this normal -f /tmp/minidlna.conf?
Last edit: Alternativend 2016-04-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1) /etc/config/minidlna is a openwrt specific config file for minidlna. It is used to generate /tmp/minidlna.conf. Head over to openwrt.org for more info.
2) You have not specified any config file with '-f'.
3) Yes, it is for openwrt (read #1).
Posting the same topic in multiple forums is considered bad etiquette.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The process is still running at this point but it doesn´t scan new titles. I have a NAS on Debian base which is running minidlna as well with the exact same files and no problems scanning the so far.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also remember having a couple rare files that would not scan when using a RT-N16 running tomato, but worked fine when I moved to using a pogoplug on Debian base.
I think it is the helper files compiled on the router are not the latest or full versions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Remove or hide the failed directories. Check the log file for the last scanned directory, then remove and restart minidlna. For example, in your debug.log:
Hi,
i had to reencode every single .ogg and .wma file in order to make minidlna not stop scanning for files. Since i have done that it scans about 33000 files, unluckily it crashes after that.
So i can see on the webinterface that it already has scanned about 30000 files and in the next moment it crashes and the proccess is killed.
Im doing a second run now since the grep command has found something else on another folder which includes an audio book in mp3. Well the files are ok as far as i can tell.
And here is the output i get on the cli:
minidlna -d -v -R -f /tmp/minidlna.conf > debug.log
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x47 0x49
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x47 0x49
Not a JPEG file: starts with 0x47 0x49
Not a JPEG file: starts with 0x47 0x49
Not a JPEG file: starts with 0x47 0x49
Not a JPEG file: starts with 0x47 0x49
Not a JPEG file: starts with 0x47 0x49
Not a JPEG file: starts with 0x47 0x49
Not a JPEG file: starts with 0x47 0x49
Not a JPEG file: starts with 0x47 0x49
Not a JPEG file: starts with 0x47 0x49
Not a JPEG file: starts with 0x47 0x49
Not a JPEG file: starts with 0x47 0x49
Application transferred too few scanlines
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x89 0x50
Not a JPEG file: starts with 0x00 0x00
Not a JPEG file: starts with 0x00 0x00
Not a JPEG file: starts with 0x00 0x00
Not a JPEG file: starts with 0x00 0x00
Segmentation fault
Second run resulted in crashing again, the grep command gives me another folder, but the end of the debug.log is actually the same.
Last edit: Alternativend 2016-04-28
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
But why is it working with the same files on a "normal" pc?
I could grant you ssh access if you would like/interested in debuging this. Somehow i start to believe that it´s a more complicated thing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I also remember having a couple rare files that would not scan when using a RT-N16 running tomato, but worked fine when I moved to using a pogoplug on Debian base.
I think it is the helper files (ffmpeg, etc.) compiled on the router are not the latest or full versions.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi there,
will it be possible to run ReadyMedia, or what it´s still called in OpenWRT minidlna on OpenWRT so that it will be acutal usable some time soon?
In the moment it keeps hanging when scanning even small libraries with just a few thousand songs because of the low RAM you have on routers´s. So in fact it´s not usable at all for the OpenWRT community and peopole using it.
So my question is, will it change sometime? Will there be a config option or some improvements in the code that will make it possible to run it with very very low RAM?
It would be really nice, cause this is the one and only DLNA program in OpenWRT and it´s completely broken.
Thanks in advance!
Anyone? Is there any chance at all?
Programs need memory to run...there's only so much one can do... maybe setup ram swap space?
Best is to find a router with more memory (I've used Asus RTN16) or just get a raspberry pi.
Last edit: HPP8140 2016-04-18
Hi,
it already has 64MB of RAM though. It´s not one of this real tiny devices, it has quite some power. I don´t know if the SWAP thing can help me because i noticed that not the whole RAM is used during the scan of minidlna, actually there is "plenty" of free RAM when it stocks.
Anyone? The developer itself maybe? I can run tests and so on if it helps you out somehow.
Last edit: Alternativend 2016-04-19
Have you run in debug mode and checked logs?
https://wiki.openwrt.org/doc/uci/minidlna
I use openwrt and minidlna on a netgear router with 64 megs just fine. Occasionally, I come across a file that causes OOM. Removing the file or rewriting the container is an easy workaround.
ssh into your router and run minidlna in debug mode using '-d -R' options to find out what is happening.
Hi,
so i have don it, here are the results.
Why claims he the parsing of an error file? Its only the config file.
Here is the debug output, do you notice that he´s opening his services on my WAN address too?!
I have removed a few video files which were in the root directory of the usb hard disk, which should not be scanned. After doing this minidlna scans about 13,000 files instead of 1,000 before. After these 13,000 he hangs as before. A complete scan should find about 30,000 files on the disk.
Im posting this here and in the OpenWRT forum, cause i don´t know who can help me.
Greetings!
Edit:
And have a look at this:
Is this normal -f /tmp/minidlna.conf?
Last edit: Alternativend 2016-04-22
1) /etc/config/minidlna is a openwrt specific config file for minidlna. It is used to generate /tmp/minidlna.conf. Head over to openwrt.org for more info.
2) You have not specified any config file with '-f'.
3) Yes, it is for openwrt (read #1).
Posting the same topic in multiple forums is considered bad etiquette.
try scanning a small subset of your media to test. I believe you have some corrupt files that it can't scan.
Hi,
but where and why? Here is the output of the complete debug.log http://pastebin.com/sDEDPJin
The process is still running at this point but it doesn´t scan new titles. I have a NAS on Debian base which is running minidlna as well with the exact same files and no problems scanning the so far.
I also remember having a couple rare files that would not scan when using a RT-N16 running tomato, but worked fine when I moved to using a pogoplug on Debian base.
I think it is the helper files compiled on the router are not the latest or full versions.
Remove or hide the failed directories. Check the log file for the last scanned directory, then remove and restart minidlna. For example, in your debug.log:
Repeat until you get a log entry like: Scanning /mnt/usb/Musik finished (xxx files)!
You can try to troubleshoot the issue but I do not want to walk you through it. Check with dmesg and go from there.
Hi,
i had to reencode every single .ogg and .wma file in order to make minidlna not stop scanning for files. Since i have done that it scans about 33000 files, unluckily it crashes after that.
So i can see on the webinterface that it already has scanned about 30000 files and in the next moment it crashes and the proccess is killed.
The last message in the normal log is:
[2016/04/27 21:15:14] playlist.c:125: warn: Parsing playlists...
I haven´t run it in debug mode yet since every file is vanished which confuses it, but i will and i will post the results.
Ok, so here we go. I have plugged in the 2,5" usb harddrive into a USB hub, just to ensure it gets enough power.
After scanning at least 28,000 files it crashes again.
Here are the last lines of the debug log http://pastebin.com/yT0RUPw9
I could send you the whole file if it helps.
Im doing a second run now since the grep command has found something else on another folder which includes an audio book in mp3. Well the files are ok as far as i can tell.
And here is the output i get on the cli:
Second run resulted in crashing again, the grep command gives me another folder, but the end of the debug.log is actually the same.
Last edit: Alternativend 2016-04-28
It appears to be crashing on another file. Figure out which file it is or remove the directory like I previously posted, using the new grep'ed folder.
But why is it working with the same files on a "normal" pc?
I could grant you ssh access if you would like/interested in debuging this. Somehow i start to believe that it´s a more complicated thing.
I also remember having a couple rare files that would not scan when using a RT-N16 running tomato, but worked fine when I moved to using a pogoplug on Debian base.
I think it is the helper files (ffmpeg, etc.) compiled on the router are not the latest or full versions.
I only have .flac, .mp3, .jpg and some .pdf files (like digital booklets) in these folders. No video´s or something like that.