minidlna config unsuccessful

[Lajos]

Hello Latenintetech!

I'm Lajos from Hungary, got an ASUS Rt-AC66U with latest Merlin and have I found Minidlna:--Common-Issues-&-Solutions wiki.

I made it through, got 2 USB drive, one is EXT3 the other is NTFS (for the media), but unfortunatelly it doesn't work for me, it still building the database in the NTFS drive's .minidlna directory. .
Reviewed the settings a lot of times, did everything as it was written.

I got that in the log:
Feb 12 18:06:54 rc_service: httpd 941:notify_rc restart_media
Feb 12 18:06:54 custom script: Running /jffs/scripts/minidlna.postconf (args: /etc/minidlna.conf)

I can see that in the /tmp/etc dir there is no minidlna.conf.system which should be, if the postconf script runs with the mv line properly .. as I understand well.

I would appreciate it if you could help me.

1 more thing:
I disconnected the NTFS usb, just have 1 USB in with EXT3 particion.
Server is running, I can reach video on it with BubbleUPnP on my phone.
I copy 1 more video to the usb with Samba, then the server is not available after, it does not shown in my BubbleUPnP anymore...

Thank you,
Lajos
edit: should I put that question to that thread:
https://www.snbforums.com/threads/minidlna-with-ext3-usb-stick-and-media-on-ntfs.9965/
?

 

[HallStevenson]

May not be the same issue that you're having, but my media server (set up on RT-N66) no longer appears as a media server with any of my devices. I noticed this some time ago but can't pinpoint if a f/w update started it or anything.

Ive toggled it off and back on, of course, as well as shortened the 'name'. Only other change I've made recently was enabling the 'Enable status webpage".

I posted about being unable to access the new 'status' page for the DLNA server in the 380.65 release thread but haven't followed-up to see if anyone commented. I do see a post from someone saying the DLNA server stopped working while it did work in the beta releases before.

 

[latenitetech]

Hello Latenintetech!

I'm Lajos from Hungary, got an ASUS Rt-AC66U with latest Merlin and have I found Minidlna:--Common-Issues-&-Solutions wiki.

I made it through, got 2 USB drive, one is EXT3 the other is NTFS (for the media), but unfortunatelly it doesn't work for me, it still building the database in the NTFS drive's .minidlna directory. .
Reviewed the settings a lot of times, did everything as it was written.

I got that in the log:
Feb 12 18:06:54 rc_service: httpd 941:notify_rc restart_media
Feb 12 18:06:54 custom script: Running /jffs/scripts/minidlna.postconf (args: /etc/minidlna.conf)

I can see that in the /tmp/etc dir there is no minidlna.conf.system which should be, if the postconf script runs with the mv line properly .. as I understand well.

I would appreciate it if you could help me.

1 more thing:
I disconnected the NTFS usb, just have 1 USB in with EXT3 particion.
Server is running, I can reach video on it with BubbleUPnP on my phone.
I copy 1 more video to the usb with Samba, then the server is not available after, it does not shown in my BubbleUPnP anymore...

Thank you,
Lajos
edit: should I put that question to that thread:
https://www.snbforums.com/threads/minidlna-with-ext3-usb-stick-and-media-on-ntfs.9965/
?

Hi Lajos,

Glad to see someone is trying this scheme I'm recommending, but also sorry you're having difficulty.

Based on the symptoms you describe, it looks like the custom minidlna.postconf isn't running since the 'mv' command you reference is the first thing that happens in that script. Also, you should see a log message coming from the script, either to say it's aborting due to a resource not found, or that it's installing a custom config file. I'm assuming you're not seeing either message. So here are some things to check:

1) Was '/jffs/scripts/minidlna.postconf' created in DOS rather than UNIX mode? The quick fix for that is just run:

 dos2unix /jffs/scripts/minidlna.postconf

2) Is '/jffs/scripts/minidlna.postconf' executable? (chmod +x /jffs/scripts/minidlna.postconf)

3) Try adding a logger line to the very start of that script to see if it's being entered:

 logger "$0:"  "Script started OK."

4) Run the minidlna.postconf script manually:

cd /jffs/scripts
./minidlna.postconf /etc/minidlna.conf

Let me know if any of that helps, and if not, I'd be glad to help further. I admit it's a bit of a convoluted setup, but once you get it working, it should work fine from then on. I've been running it reliably for several months now, through multiple firmware upgrades (now on 380.65) without a blip.

 

[PetrKKK]

Hello, after installing newest Merlin firmware 380.65 to my RT AC66U I have DLNA problems described here .
Solution for me was to downgrade to 380.64_2.

 

[Lajos]

Hi Lajos,

Glad to see someone is trying this scheme I'm recommending, but also sorry you're having difficulty.

Based on the symptoms you describe, it looks like the custom minidlna.postconf isn't running since the 'mv' command you reference is the first thing that happens in that script. Also, you should see a log message coming from the script, either to say it's aborting due to a resource not found, or that it's installing a custom config file. I'm assuming you're not seeing either message. So here are some things to check:

1) Was '/jffs/scripts/minidlna.postconf' created in DOS rather than UNIX mode? The quick fix for that is just run:

 dos2unix /jffs/scripts/minidlna.postconf

2) Is '/jffs/scripts/minidlna.postconf' executable? (chmod +x /jffs/scripts/minidlna.postconf)

3) Try adding a logger line to the very start of that script to see if it's being entered:

 logger "$0:"  "Script started OK."

4) Run the minidlna.postconf script manually:

cd /jffs/scripts
./minidlna.postconf /etc/minidlna.conf

Let me know if any of that helps, and if not, I'd be glad to help further. I admit it's a bit of a convoluted setup, but once you get it working, it should work fine from then on. I've been running it reliably for several months now, through multiple firmware upgrades (now on 380.65) without a blip.

Hi Latenintetech,

Thank you for your reply and I appreciate your help.

I checked all you have mentioned and by running the script manually, it turned out that when I had copied the config files' content from your wiki to nano (through PuTTY) the long lines had splitted, so unrunnable, non-outcommented lines had created in this way.

After correcting these errors and running the script manually I can see that in the system log:

Feb 13 22:06:48 luikang: ./minidlna.postconf: Script started OK.
Feb 13 22:06:48 luikang: ./minidlna.postconf: Installing custom minidlna.conf in /etc

BUT... when I start the Media Server from the WebGUI of the router, and then look into the /opt/app/minidlna/ folder, there is no db, but it is in tht root/.minidlna...
Looking into the /etc/minidlna.conf I can see it is the original, not the merged one with the original path:

db_dir=/tmp/mnt/sda1/.minidlna

Any idea?

 

[latenitetech]

Hi Latenintetech,

Thank you for your reply and I appreciate your help.

I checked all you have mentioned and by running the script manually, it turned out that when I had copied the config files' content from your wiki to nano (through PuTTY) the long lines had splitted, so unrunnable, non-outcommented lines had created in this way.

After correcting these errors and running the script manually I can see that in the system log:

Feb 13 22:06:48 luikang: ./minidlna.postconf: Script started OK.
Feb 13 22:06:48 luikang: ./minidlna.postconf: Installing custom minidlna.conf in /etc

BUT... when I start the Media Server from the WebGUI of the router, and then look into the /opt/app/minidlna/ folder, there is no db, but it is in tht root/.minidlna...
Looking into the /etc/minidlna.conf I can see it is the original, not the merged one with the original path:

db_dir=/tmp/mnt/sda1/.minidlna

Any idea?

Glad to see you're making progress, but it still seems like you have a problem with the minidlna.postconf script.
1) After running it manually, look at '/etc/minidlna.conf'. Does it look like the correct merged version then?
2) The quoted log entries in your post I assume are from the manually-invoked 'minidlna.postconf'. Did you see those same log entries right after you started minidlna from the WebGUI? They would have immediately followed 'custom script: Running /jffs/scripts/minidlna.postconf (args: /etc/minidlna.conf)'. Did you see that happen in the system log?
3) The first "real" action of the minidlna.postconf script is to "set aside" the system generated file (the 'mv' line). Is there a 'minidlna.conf.system' in '/etc' after starting minidlna from the WebGUI?
4) If you still can't see what's happening, could you attach copies of your 'minidlna.postconf' and
'minidlna.conf.base' files here? You'll probably need to add a fake suffix like '.txt' to each one so they'll upload.

 

[HallStevenson]

Someone in the 380.65 release thread mentioned that users with "66" routers seem to be the ones having issues with the media server. The OP has a 66, I have a 66. All of this troubleshooting and re-configuring may be all for naught.

 

[latenitetech]

Someone in the 380.65 release thread mentioned that users with "66" routers seem to be the ones having issues with the media server. The OP has a 66, I have a 66. All of this troubleshooting and re-configuring may be all for naught.

I think we're discussing 2 different issues here. Lajos is having problems getting a specific setup working (one that I recommend in a Wiki article I wrote). He's not yet at the point where it is successfully launching minidlna as intended.

The issues being reported relative to 380.65 seem to be around minidlna hanging when a new file is added to the library. I suspect that issue ties back to the significant changes made in how 'inotify' is handled in minidlna in 380.65. Once Lajos gets past his current issues with his start-up config, he may well hit the 380.65 issue and want to revert back to a previous FW, but let's take this one step at a time.

 

[HallStevenson]

No problem - you're into this pretty good !

By the way, after deleting the various .minidlna folders, the built-in media server is now showing up. Well, I've checked it via my TV so far only.

 

[Lajos]

Glad to see you're making progress, but it still seems like you have a problem with the minidlna.postconf script.
1) After running it manually, look at '/etc/minidlna.conf'. Does it look like the correct merged version then?
2) The quoted log entries in your post I assume are from the manually-invoked 'minidlna.postconf'. Did you see those same log entries right after you started minidlna from the WebGUI? They would have immediately followed 'custom script: Running /jffs/scripts/minidlna.postconf (args: /etc/minidlna.conf)'. Did you see that happen in the system log?
3) The first "real" action of the minidlna.postconf script is to "set aside" the system generated file (the 'mv' line). Is there a 'minidlna.conf.system' in '/etc' after starting minidlna from the WebGUI?
4) If you still can't see what's happening, could you attach copies of your 'minidlna.postconf' and
'minidlna.conf.base' files here? You'll probably need to add a fake suffix like '.txt' to each one so they'll upload.

OK.

Preparation:
- I've made sure the /etc/minidlna.conf is exists
- I've deleted the /etc/minidlna.conf.system

1)
I ran the script manually, checked the /etc/minidlna.conf -> it seems ok:
"db_dir=/opt/app/minidlna" is correct in it, and other entries, like uuid is exists inside.
The /etc/minidlna.conf.system was created.
The /opt/app/minidlna/.minidlna.conf.merged is created/modified.
No other file resides here, except the .base ofc.

Log:

Feb 14 08:11:41 luikang: ./minidlna.postconf: Script started OK.
Feb 14 08:11:41 luikang: ./minidlna.postconf: Installing custom minidlna.conf in /etc

2)
Preparation:
- I've deleted the /etc/minidlna.conf.system

I switched on the MediaServer from the WebGUI.
Now an error appeared in the log I've never seen:

Log:

Feb 14 08:23:01 rc_service: httpd 8433:notify_rc restart_media
Feb 14 08:23:02 custom script: Running /jffs/scripts/minidlna.postconf (args: /etc/minidlna.conf)
Feb 14 08:23:02 kernel: EXT3-fs error (device sda1): htree_dirblock_to_tree: bad entry in directory #73022: inode out of bounds - offset=0, inode=536943934, rec_len=12, name_len=1
Feb 14 08:23:03 kernel: EXT3-fs error (device sda1): htree_dirblock_to_tree: bad entry in directory #73022: inode out of bounds - offset=0, inode=536943934, rec_len=12, name_len=1

The /etc/minidlna.conf is the old again.

3) After 2), there is no /etc/minidlna.conf.system

4) See the files attached.

 

[latenitetech]

First, I can visually see 2 problems in your minidlna.postconf file:
1) The first line of the file should be the '#!/bin/sh', and then you can make the second line the extra logger you added. A shell script should always start with the '#!/bin/sh' as it tells the OS what interpreter to load to read the remainder of the file. I don't think it's causing your issue though, as 'sh' is the default interpreter, but best to fix it and be aware of that for the future. [And I know I said to add that logger line to the beginning of the file earlier, but I should have been more explicit about adding it as the second line. Sorry. ]

2) You still have an unintended word wrap at line 37 (the word 'startup' should be part of the previous line, but it's on a line of its own). That's probably your problem. It wouldn't have affected the script when running it manually because the 'if' statement at line 35 would never be true, but it would be a code error during boot when we expect the script to be called multiple times (once for each volume mount), and that's the code block that causes the intermediate exits to occur.

So, obviously fix that error, and consider turning off word wrap in your setup, and/or set your display width wider so it would have been more obvious to you.

But, aside from the above, those new errors in your logfile are the bigger problem to address first. They indicate you have corruption in your EXT3 volume that need to be fixed by running e2fsck on the volume. I'm going to assume that may be new to you as well, so don't be offended if I'm telling you too much here ...

First, is your EXT3 volume on a flash drive or spinning HDD? It's preferable to use EXT2 on a flash drive as it's a non-journaling filesystem that is more efficient and less wear on flash drives. EXT3 would be recommended for a traditional HDD. But that's just a recommendation, and shouldn't be an issue here either way. If it turns out you need to reformat that volume to get rid of the 'EXT3-fs error (device sda1)' errors, and it is indeed a flash drive, consider using EXT2.

The router has a built-in disk check capability (via the WebGUI), but it only works if all access is removed from the volume first. For example, if you're running a swapfile or Entware on that volume, you would first need to stop the swapfile and/or all Entware activity. I could spend a lot of time here explaining all the nuances of this, but if you're not already familiar with it, I'm going to recommend you take a look at another Wiki article I wrote:
https://github.com/RMerl/asuswrt-merlin/wiki/USB-Disk-Check-at-Boot

An advantage of running the disk check at boot is it occurs before anything else runs, so it won't be locked out by something already accessing the volume.

Hopefully the disk check will fix the corruption in your sda1 volume, then with the fixes to the minidlna.postconf script, everything will then work properly. Fingers crossed!

 

[Lajos]

First, I can visually see 2 problems in your minidlna.postconf file:
1) The first line of the file should be the '#!/bin/sh', and then you can make the second line the extra logger you added. A shell script should always start with the '#!/bin/sh' as it tells the OS what interpreter to load to read the remainder of the file. I don't think it's causing your issue though, as 'sh' is the default interpreter, but best to fix it and be aware of that for the future. [And I know I said to add that logger line to the beginning of the file earlier, but I should have been more explicit about adding it as the second line. Sorry. ]

2) You still have an unintended word wrap at line 37 (the word 'startup' should be part of the previous line, but it's on a line of its own). That's probably your problem. It wouldn't have affected the script when running it manually because the 'if' statement at line 35 would never be true, but it would be a code error during boot when we expect the script to be called multiple times (once for each volume mount), and that's the code block that causes the intermediate exits to occur.

So, obviously fix that error, and consider turning off word wrap in your setup, and/or set your display width wider so it would have been more obvious to you.

But, aside from the above, those new errors in your logfile are the bigger problem to address first. They indicate you have corruption in your EXT3 volume that need to be fixed by running e2fsck on the volume. I'm going to assume that may be new to you as well, so don't be offended if I'm telling you too much here ...

First, is your EXT3 volume on a flash drive or spinning HDD? It's preferable to use EXT2 on a flash drive as it's a non-journaling filesystem that is more efficient and less wear on flash drives. EXT3 would be recommended for a traditional HDD. But that's just a recommendation, and shouldn't be an issue here either way. If it turns out you need to reformat that volume to get rid of the 'EXT3-fs error (device sda1)' errors, and it is indeed a flash drive, consider using EXT2.

The router has a built-in disk check capability (via the WebGUI), but it only works if all access is removed from the volume first. For example, if you're running a swapfile or Entware on that volume, you would first need to stop the swapfile and/or all Entware activity. I could spend a lot of time here explaining all the nuances of this, but if you're not already familiar with it, I'm going to recommend you take a look at another Wiki article I wrote:
https://github.com/RMerl/asuswrt-merlin/wiki/USB-Disk-Check-at-Boot

An advantage of running the disk check at boot is it occurs before anything else runs, so it won't be locked out by something already accessing the volume.

Hopefully the disk check will fix the corruption in your sda1 volume, then with the fixes to the minidlna.postconf script, everything will then work properly. Fingers crossed!

OMG, it works now!

Sorry, all the problem was about the long lines... and my noobness in Linux command line usage...

I had done the checkdisk - and it had repaired some sectors, then I did the correction in the config files.
I'll take your advice and I'll use EXT2 on the USB drive - I would like to change it to an other one anyway.

Thank you very much, God bless you for your kindness!

Now I see that if I put a new file into the shared folder, the server goes unreachable and need to do a restart... so I do a firmware revert now.

 

[latenitetech]

Great! So glad you got through the issues. But now I'm curious about the problem you're seeing with minidlna failing when adding a file to your library, which appears to be specific to the *66* line of routers on the latest firmware.

When it fails, are there any messages in the system log or the minidlna log? Is minidlna still running (as determined by running 'ps | grep minidlna')? I don't have a '66' router (mine is a '68'), so I'm not seeing this problem, but getting more failure info back to Rmerlin will certainly help him get to the root cause.

 

[Lajos]

Great! So glad you got through the issues. But now I'm curious about the problem you're seeing with minidlna failing when adding a file to your library, which appears to be specific to the *66* line of routers on the latest firmware.

When it fails, are there any messages in the system log or the minidlna log? Is minidlna still running (as determined by running 'ps | grep minidlna')? I don't have a '66' router (mine is a '68'), so I'm not seeing this problem, but getting more failure info back to Rmerlin will certainly help him get to the root cause.

I'm glad to help.
After the revert everything goes well, I've added an NTFS drive to the 2nd USB port and it worked well.
Except my family photos (~6MB) are not showing on BubbleUpnp (error downloading) - if converted down it works.

I've reinstalled the latest firmware and tried the server. It was good up until I added 1 file over Samba to one of the drive.
Then the MediaServer disappeared from the list and not working again.

In the log: (seems not the problem, but maybe can cause - I have the "allow guest users without authenticating" checked on at Samba settings)

Feb 14 23:54:23 smbd[713]: [2017/02/14 23:54:23.484201,  0] ../libcli/auth/ntlm_check.c:54(smb_pwd_check_ntlmv1)
Feb 14 23:54:23 smbd[713]:   smb_pwd_check_ntlmv1: incorrect password length (68)

'ps | grep minidlna':

  709 luikang   6928 S N  minidlna -f /etc/minidlna.conf -r -W
  875 luikang   7000 S N  minidlna -f /etc/minidlna.conf -r -W
  897 luikang   1448 S    grep minidlna

Tell me what should I check.

 

[latenitetech]

I'm glad to help.
After the revert everything goes well, I've added an NTFS drive to the 2nd USB port and it worked well.
Except my family photos (~6MB) are not showing on BubbleUpnp (error downloading) - if converted down it works.

I've reinstalled the latest firmware and tried the server. It was good up until I added 1 file over Samba to one of the drive.
Then the MediaServer disappeared from the list and not working again.

In the log: (seems not the problem, but maybe can cause - I have the "allow guest users without authenticating" checked on at Samba settings)

Feb 14 23:54:23 smbd[713]: [2017/02/14 23:54:23.484201,  0] ../libcli/auth/ntlm_check.c:54(smb_pwd_check_ntlmv1)
Feb 14 23:54:23 smbd[713]:   smb_pwd_check_ntlmv1: incorrect password length (68)

'ps | grep minidlna':

  709 luikang   6928 S N  minidlna -f /etc/minidlna.conf -r -W
  875 luikang   7000 S N  minidlna -f /etc/minidlna.conf -r -W
  897 luikang   1448 S    grep minidlna

Tell me what should I check.

Any errors in the minidlna.log file related to the "add a file and it goes away" failure? (The log file should be in the db_dir '/opt/app/minidlna' for you I believe.)

When I run the ps command (when minidlna is running properly), I see 3 processes (not including the 'grep' line you show), while you have 2. I don't know the internal architecture of minidlna to know why there are multiple processes, but I assume each one is just handling a specific aspect of the service, and they're all named the same simply as a consequence of the system Linux uses to spawn subprocesses. But the point is, 3 seems to be "normal" and one may be dying when a file is added to the library via Samba.

Just to verify, do you see 3 'minidlna -f /etc ...' processes as well when it's running correctly?

The smbd lines from the log are from Samba, so I doubt are related to the minidlna issue. One thing that might be interesting to try though, add a media file to your library from a Linux command prompt rather than via Samba, and see if that breaks minidlna. I suspect it will, as I'm thinking the problem is related to the 'inotify' function, which triggers minidlna to update it's database when it detects a change in a media directory. The inotify should trigger regardless of the source (Samba or a command shell), but it may be interesting to know if one way works and the other doesn't.

One other thing you might be interested in relative to photo sharing: there is a related option in the minidlna.conf.base file "strict_dlna" by default set to "no." Per the man page:

strict_dlna
Set to “yes” to strictly adhere to DLNA standards. This will
allow server-side downscaling of very large JPEG images, which
may hurt JPEG serving performance on (at least) Sony DLNA
products. Set to “no” otherwise.

So you might want to play with that (set it to yes and restart minidlna) and see if it solves your photo sharing issue. (I don't personally do photo-sharing in my setup, so I can't say one way or another what it does or if it works.)

 

[Lajos]

Here are my inspection results:

Running mediaserver:

ps | grep minidlna:

 3065 luikang   7084 S    minidlna -f /etc/minidlna.conf -r -W
 3067 luikang   7084 S    minidlna -f /etc/minidlna.conf -r -W
 3068 luikang   7084 S N  minidlna -f /etc/minidlna.conf -r -W

Copying a new file to the shared directory via SAMBA, Mediaserver still works, but the new file doesn't appear. .
I do a Refresh in BubbleUPnP... after a while Browse error, Action timeout.

ps | grep minidlna:

 3068 luikang   7100 S N  minidlna -f /etc/minidlna.conf -r -W
 3128 luikang   7100 S N  minidlna -f /etc/minidlna.conf -r -W
 3139 luikang   1448 S    grep minidlna

Minidlna.log contains no new entry.

The same occur if I copy the file via Linux 'cp'... as you expected.



Running Mediaserver with strict_dlna=yes:
Minidlna.log:

[2017/02/15 22:15:23] minidlna.c:1286: warn: Starting MiniDLNA version 1.1.6.
[2017/02/15 22:15:24] minidlna.c:1326: warn: HTTP listening on port 8200
[2017/02/15 22:15:24] inotify.c:262: warn: rows=add_watch_subdir,1-num_watches
[2017/02/15 22:15:24] inotify.c:262: warn: rows=add_watch_subdir,2-num_watches
[2017/02/15 22:15:24] inotify.c:231: warn: add_watch--dir_path=/tmp/mnt/KINGSTON/2016 Karácsony
[2017/02/15 22:15:24] inotify.c:266: warn: rowes=3, num_watches=3
[2017/02/15 22:19:29] image_utils.c:415: warn: malloc failed
[2017/02/15 22:19:29] upnphttp.c:2343: warn: Unable to open image /tmp/mnt/KINGSTON/IMG_20160923-201647_1246.JPG!
[2017/02/15 22:19:38] image_utils.c:415: warn: malloc failed

And the pictures are not showing, just cause the router's CPU to be constantly at 100% for a long time...

 

[latenitetech]

Here are my inspection results:

Running mediaserver:

ps | grep minidlna:

 3065 luikang   7084 S    minidlna -f /etc/minidlna.conf -r -W
 3067 luikang   7084 S    minidlna -f /etc/minidlna.conf -r -W
 3068 luikang   7084 S N  minidlna -f /etc/minidlna.conf -r -W

Copying a new file to the shared directory via SAMBA, Mediaserver still works, but the new file doesn't appear. .
I do a Refresh in BubbleUPnP... after a while Browse error, Action timeout.

ps | grep minidlna:

 3068 luikang   7100 S N  minidlna -f /etc/minidlna.conf -r -W
 3128 luikang   7100 S N  minidlna -f /etc/minidlna.conf -r -W
 3139 luikang   1448 S    grep minidlna

Minidlna.log contains no new entry.

The same occur if I copy the file via Linux 'cp'... as you expected.



Running Mediaserver with strict_dlna=yes:
Minidlna.log:

[2017/02/15 22:15:23] minidlna.c:1286: warn: Starting MiniDLNA version 1.1.6.
[2017/02/15 22:15:24] minidlna.c:1326: warn: HTTP listening on port 8200
[2017/02/15 22:15:24] inotify.c:262: warn: rows=add_watch_subdir,1-num_watches
[2017/02/15 22:15:24] inotify.c:262: warn: rows=add_watch_subdir,2-num_watches
[2017/02/15 22:15:24] inotify.c:231: warn: add_watch--dir_path=/tmp/mnt/KINGSTON/2016 Karácsony
[2017/02/15 22:15:24] inotify.c:266: warn: rowes=3, num_watches=3
[2017/02/15 22:19:29] image_utils.c:415: warn: malloc failed
[2017/02/15 22:19:29] upnphttp.c:2343: warn: Unable to open image /tmp/mnt/KINGSTON/IMG_20160923-201647_1246.JPG!
[2017/02/15 22:19:38] image_utils.c:415: warn: malloc failed

And the pictures are not showing, just cause the router's CPU to be constantly at 100% for a long time...

So it looks like you confirmed one of the 3 minidlna processes is dying when adding a new file to the media library, whether you do it via Samba or directly. Good bit of detective work. I'm afraid your only option at this point is to downgrade the firmware to a previous version unless you're willing to live with not being able to add media to your library without restarting minidlna each time. Hopefully Rmerlin will find and fix the bug you're experiencing here.

As for the strict_dlna flag, it appears minidlna is trying to resize your large pic(s) on the fly, and running out of memory doing so. I'm going to assume you're not running a swap file, as that would probably fix the malloc errors. This is totally your call how much you want to pursue this. Setting up a swap file on your flash drive may get past this error, but I have no idea if it will actually improve things for you. May just want to bail and turn that flag off again.

 

[Lajos]

So it looks like you confirmed one of the 3 minidlna processes is dying when adding a new file to the media library, whether you do it via Samba or directly. Good bit of detective work. I'm afraid your only option at this point is to downgrade the firmware to a previous version unless you're willing to live with not being able to add media to your library without restarting minidlna each time. Hopefully Rmerlin will find and fix the bug you're experiencing here.

As for the strict_dlna flag, it appears minidlna is trying to resize your large pic(s) on the fly, and running out of memory doing so. I'm going to assume you're not running a swap file, as that would probably fix the malloc errors. This is totally your call how much you want to pursue this. Setting up a swap file on your flash drive may get past this error, but I have no idea if it will actually improve things for you. May just want to bail and turn that flag off again.

Dear Latenintetech,

I have an 512MB swap file running, I didn't report that to you. With 'free' command I saw that it was mostly unused, at that 100% load time it was used for like 50MB.

How RMerlin will be notified about these results?

I am thinking now about an automatic syncronising - dowgrading utility which can run on my PC...

Latenintetech, thank you again for your help.

 

[latenitetech]

I have an 512MB swap file running, I didn't report that to you. With 'free' command I saw that it was mostly unused, at that 100% load time it was used for like 50MB.

Interesting ... usually malloc errrors are solved by a swapfile, but perhaps that code around "strict_dlna=yes" is just buggy. I've never tried it, so can't confirm.

How RMerlin will be notified about these results

Just by being discussed here will probably cover it, as I believe Rmerlin (Eric) usually peruses most of these threads. But if you wanted to be sure, you could post a short summary of what you're learned in the 'Asuswrt-Merlin 380.65 is now available' thread.

Latenintetech, thank you again for your help.

You're very welcome. Always glad to see others be successful and grow their technical skills here.