What's new

Asuswrt-Merlin 3.0.0.4.374.33 Beta 5 available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Strange. I switched off the DLNA server. rebooted the router (AC66U) and tried that runtime that you made available last week. I can access the files on my usb disks from AiClould even as the server is scanning my music directory. That is something I can't do with beta 5.

http://www.mediafire.com/download/u6...t/minidlna.zip This is the 1.1.0 version with the build 374 changes reverted.

This is what's working for me. I find that very strange.
 
Just waiting to see if beta5b SDK5 has solved the channel changing problem with the N66U then I may give it a go. :cool: BTW is there still a issue with the clock sync in this version ?
 
Last edited by a moderator:
beta 5 working well, feels faster on both wired throughput and wireless, thanks for your hard work.
 
Strange. I switched off the DLNA server. rebooted the router (AC66U) and tried that runtime that you made available last week. I can access the files on my usb disks from AiClould even as the server is scanning my music directory. That is something I can't do with beta 5.

http://www.mediafire.com/download/u6...t/minidlna.zip This is the 1.1.0 version with the build 374 changes reverted.

This is what's working for me. I find that very strange.

What happens if you stop the built-in DLNA, then start it manually (using the minidlna binary from the firmware, not the downloaded one)? Can you reproduce the same result? If yes, then it means the issue isn't with the minidlna binary itself, but with how it gets started.
 
Last edited:
Just waiting to see if beta5b SDK5 has solved the channel changing problem with the N66U then I may give it a go. :cool: BTW is there still a issue with the clock sync in this version ?

The channel issue with the SDK5 build is fixed - I was able to reproduce it, and test afterward.

Can you elaborate on your clock sync issue? I don't recall any specific issue with the initial sync itself - the issue had to do with the router not realizing the clock had been synced, which caused the warning to get displayed on some pages like the Wireless page. That issue has been fixed as noted in the changelog, along with a few other potential issues that might have prevented the radio schedule from working.
 
beta 5 working well, feels faster on both wired throughput and wireless, thanks for your hard work.

Nice, except that nothing was changed in regard to general performance or wireless driver :) A fresh reboot can do wonders at times.
 
I will start testing the Parent Controls and let you know..
Thanks for your hard work. and all you do.

FYI;
Been running ddwrt, but I rather test this for you.

Chris
 
What happens if you stop the built-in DLNA, then start it manually (using the minidlna binary from the firmware, not the downloaded one)? Can you reproduce the same result? If yes, then it means the issue isn't with the minidlna binary itself, but with how it gets started.


Sure I can do that, but how do I do that. I don't know much about linux.
 
I am having problem with the AiCloud 2.0. Whenever I attempted to click at my USB connected HDD (NTFS or EXT3 format), I always got the "Server Error! Please refresh page." error message. There is no way to access my HDD. The scenario already occurred with Beta 3. So I tried to revert back to the original ASUS FW 374_726 and the AiCloud 2.0 is working fine without error. Is there any changes causing such error with the external HDD connected to the router.
 
I am having problem with the AiCloud 2.0. Whenever I attempted to click at my USB connected HDD (NTFS or EXT3 format), I always got the "Server Error! Please refresh page." error message. There is no way to access my HDD. The scenario already occurred with Beta 3. So I tried to revert back to the original ASUS FW 374_726 and the AiCloud 2.0 is working fine without error. Is there any changes causing such error with the external HDD connected to the router.

turn off DLNA until the bugs fixed m8. if you read the thread you would see a couple of us have this issue :)
 
Sure I can do that, but how do I do that. I don't know much about linux.

I was able to spend some time looking at this tonight.

The malloc() error in your log isn't critical. I checked the code referenced by your log entry, and it simply means minidlna tried to allocate memory to process an image that was too big. Minidlna reported it, and properly handled it as indicated by your log file - it continued scanning, completing a minute later. So that malloc() error isn't a problem in itself.

Regarding minidlna's scanning: I just tossed my entire collection of music and TV shows at it (essentially hundred of gigs of music and videos). After one hour of scanning I stopped it as it was still working through it, but during that time it never crashed, and only logged three errors about three thumbnail jpegs it was unable to process. The database was at 35 MB and still growing by the time I stopped it.

The AiCloud issue seems to be a bug in the closed-source module. The reason why you weren't experiencing the crash when running the test minidlna build is because AiCloud didn't know that minidlna was running, and was ignoring it. However, the minute you set the nvram value for minidlna as being enabled:

Code:
nvram set dms_enable=1

it won't even matter if minidlna is really running or not: Accessing a local HDD over AiCloud will cause the lighttpd process to segfault, leading to the server error message that you see.

Unfortunately, that code is closed-source by Asus, so I cannot look at it, even less fix it. The only workaround I can see for now is to not enable minidlna if you intend to use AiCloud with a local disk.

I'll see if I can find more time this week to create a simple test case so I can report it to Asus.
 
All things considered, 802.11h really only applies to the 5GHz radio, and in the US, would only unlock the UNII-2 (ch52-64) and potentially the UNII-2 Extended (ch100-140) bands.

802.11d would apply to both since it's adding a country code to the 802.11 beacon.

I noticed the UI independently exposes both options on both bands. Not sure enabling 802.11h on the 2.4GHz band is meaningful or useful in this context.
 
All things considered, 802.11h really only applies to the 5GHz radio, and in the US, would only unlock the UNII-2 (ch52-64) and potentially the UNII-2 Extended (ch100-140) bands.

802.11d would apply to both since it's adding a country code to the 802.11 beacon.

I noticed the UI independently exposes both options on both bands. Not sure enabling 802.11h on the 2.4GHz band is meaningful or useful in this context.

Yeah, I was thinking about that, I just couldn't be 100% sure since that var is accessed by the closed-source driver, and wasn't entirely sure either if maybe there was anything else in the 802.11h standard that could apply to the 2.4 GHz band.

I'll try to find more documentation that what Wikipedia provided me on my quick check, and will hide the 802.11h and combined d+h modes on the 2.4 GHz if I can find confirmation that it doesn't apply at all to that band.
 
There's some old size check code from Tomato still lingering around, and I suspect it's causing issues with the N16 and N66 whenever you flash a firmware that resizes the JFFS2 partition.

Try unsetting the size variable through ssh/telnet:

Code:
nvram unset jffs2_size
nvram commit

Then reboot a first time. Store something in the jffs2 partition, then reboot a second time to check that this content is still there.

So far I've been unable to reproduce it, but I suspect it's related to that size code (the AC66/AC56 are unaffected since their jffs partition never changes size). I will probably end up pulling out that piece of code if it's too buggy.

Ok, after the two commands, it's working fine now.
Thanks :)
 
I was able to spend some time looking at this tonight.

The malloc() error in your log isn't critical. I checked the code referenced by your log entry, and it simply means minidlna tried to allocate memory to process an image that was too big. Minidlna reported it, and properly handled it as indicated by your log file - it continued scanning, completing a minute later. So that malloc() error isn't a problem in itself.

Regarding minidlna's scanning: I just tossed my entire collection of music and TV shows at it (essentially hundred of gigs of music and videos). After one hour of scanning I stopped it as it was still working through it, but during that time it never crashed, and only logged three errors about three thumbnail jpegs it was unable to process. The database was at 35 MB and still growing by the time I stopped it.

The AiCloud issue seems to be a bug in the closed-source module. The reason why you weren't experiencing the crash when running the test minidlna build is because AiCloud didn't know that minidlna was running, and was ignoring it. However, the minute you set the nvram value for minidlna as being enabled:
[.

Thx Merlin. I wasn't concerned about the malloc() errror to begin with because I know what's causing that, although I didn't know that an image could be too big to scan. I use iTunes to retrieve the album art for the music in my library, but sometimes the art isn't available from iTunes and then I just google it up.

As for scanning my music library, I haven't said that the scanning crashes when I use the build in Media Server. It just prevents me from accessing my files from my AiCloud iOS app. It's not something that is crucial, but I would like it solved. The DLNA server is far more important too me, since I use that one every day.

Thx for letting Asus know that there is a problem. Keep up the amazing work on the firmware. I'm surprised that Asus hasn't hired you yet.
 
Last edited:
about dlna

Hi guys,

I see that there is some issue with dlna here, I wanted to check with u guys about an issue.

If I run hdd docking station with 2 hdd´s, 2tb per hdd and connect it to the rt-n66u with 1 usb cable. Is it possible for the DLNA to find both hdd? I can see them both when we tested to scan for the files it just sayed scanning. And where should the database file be stored? On hdd´s?

Under dlna settings I did set /mount for the filer, should I set /mount for the database?
 
Hi guys,

I see that there is some issue with dlna here, I wanted to check with u guys about an issue.

If I run hdd docking station with 2 hdd´s, 2tb per hdd and connect it to the rt-n66u with 1 usb cable. Is it possible for the DLNA to find both hdd? I can see them both when we tested to scan for the files it just sayed scanning. And where should the database file be stored? On hdd´s?

Under dlna settings I did set /mount for the filer, should I set /mount for the database?

Check out this link. This should help.
http://wiki.openwrt.org/doc/uci/minidlna
 
I'm using Beta1. Have I to do a nvram setting reset if I want to try this Beta5?

The $10 million question: what router model?
 
Under dlna settings I did set /mount for the filer, should I set /mount for the database?

No, otherwise that means the database will be in RAM, which can quickly fill up. Point the database to a location on the hard disk where you wish to store the database.
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top