Related
I don't have data to spare to test things myself until next month, and have a fairly stable PPP setup anyway.
But I figured if someone wants to experiment the following might be worth a shot.
What I've done is attach a zip with 4 sample options files for pppd that attempt to address issues I've seen with pppd. Specifically the crash with memory issues due to compression, and pppd dying when disconnected and needing to be restarted (eg by LeTama's v0.3 wrapper). If you want to try these out I would suggest using them in conjunction with his wrapper as I'm unsure how other versions may work: http://forum.xda-developers.com/showthread.php?t=824413
The 4 versions for testing are as follows:
option1
- Makes the buffer size used for compression as small as possible.
- Tries to make the connection persistant.
option2
- Disables compression.
- Tries to make the connection persistant.
option3
- Makes the buffer size used for compression as small as possible.
option4
- Disables compression.
To use them they will need to be copied to your /etc/ppp/ folder as "options" and you'll need to ensure it's readable.
If you don't know what I mean I suggest you don't bother trying this.
If you do know what you're doing then you can try experimenting with the different options and see if they make things better/worse.
option3 is probably the safest, option4 may be needed if things still crash due to memory issues with option3.
option1 would be the ideal, but I can't guarantee the persist option is possible.
If option1 or option3 prove to improve things and prevent the crash, then the values used could be slowly increased (to a max of 15) to see if crashes start happening again.
Anyway, just something else the more adventurous and tech savvy users out there with PPP issues can try.
Can I copy these over via ADB push while Android is running, or do I need to put them in the Android root folder so they'll get copied into place on reboot?
Well with Option 1 the data connections drops almost instantly, Option 2 is doing without drops for 10 min now, but it is too early to say if it's an improvement over the old options.
Does compression influence the connection speed? Option 2 works as fast as possible on HSDPA... Option 2 dropped after about 15 minutes when downloading from the market, but downloading from the market was much faster than before.
Should we be copying it as "options" with no file extension or "options.smd"?
Probably as options.smd, that's what I did and it seemed to have some effect...
Now testing option3, will mess with it for the rest of the day and see what happens. At first glance, it seems a bit slow, but that's anecdotal at best.
MAsterokki said:
Well with Option 1 the data connections drops almost instantly, Option 2 is doing without drops for 10 min now, but it is too early to say if it's an improvement over the old options.
Does compression influence the connection speed? Option 2 works as fast as possible on HSDPA... Option 2 dropped after about 15 minutes when downloading from the market, but downloading from the market was much faster than before.
Click to expand...
Click to collapse
Seems like I drew my conclusion from Option 1 too early, after a reboot it works great, I have been downloading MDJ newest rom for 10 min now which resulted 20% of 170mb (from multiupload). No drops untill now, definitely a huge improvement over the old options.smd. Thanks alot Hastarin!
question when i get to the ppp file in i see options.smd and a options.smd1 do i just add this new option to it or delete the old ones and replace with this one?
imphoking said:
question when i get to the ppp file in i see options.smd and a options.smd1 do i just add this new option to it or delete the old ones and replace with this one?
Click to expand...
Click to collapse
I would backup your original files first, although the orig options.smd is probably blank anyhow.
Replace the options.smd with the renamed options from hastarin.
Hastarin, do you happen to know the default options when we were using the default "blank" options.smd? Does it use compression etc. Thanks for your efforts!
noellenchris said:
Hastarin, do you happen to know the default options when we were using the default "blank" options.smd? Does it use compression etc. Thanks for your efforts!
Click to expand...
Click to collapse
The wrapper supplies nodetach, debug and something I can't recall atm (should be in IRC logs).
Compression will be used by pppd by default but I couldn't find information on what size buffer it uses by default.
Google pppd man page for more information.
You are right about options.smd being the safest option. Using options file may affect other things that use pppd if there are any.
Sent from my HTC HD2
Option1 seems to be working fine for me right now. I will report more in a few hours while I'm out.
Hey just wanted to say that I am checking out these options also. So far using option1 and I haven't had any data drops or freezes. Haven't been able to test it extensively yet but will over the next few hours.
With option 1 can you make sure you can switch between WiFi and data and back again? And that you can turn mobile data off and on? And perhaps airplane mode and back to be thorough?
Thanks
Sent from my HTC HD2
It seems after some time options.smd gets reset to blank by itself? Anyone noticed?
Sent from my HTC HD2 using XDA App
memin1857 said:
It seems after some time options.smd gets reset to blank by itself? Anyone noticed?
Sent from my HTC HD2 using XDA App
Click to expand...
Click to collapse
I haven't rebooted yet, but mine is still there and not blank. I will try to toggle wifi etc next. Otherwise it's still rolling well, no disconnects yet or hangs.
memin1857 said:
It seems after some time options.smd gets reset to blank by itself? Anyone noticed?
Sent from my HTC HD2 using XDA App
Click to expand...
Click to collapse
I set mine to read only in case this actually happens lol.
noellenchris said:
I haven't rebooted yet, but mine is still there and not blank. I will try to toggle wifi etc next. Otherwise it's still rolling well, no disconnects yet or hangs.
Click to expand...
Click to collapse
Lucky.. I still can't get mine to last longer than 5 seconds.
Ok with option1 I started experiencing some data freeze again. It happened while downloading a large file and then again when I switched to wifi tethering. The freeze actually freezes my entire system and then my phone runs really really slow. It may be the build that I am using so I am going to try an older build that did not seem to have this problem. I will run option1 for a while again and then try the others.
Option 1 is no good - I think the persist option keeps 3g "connected" even though I'm getting timeouts, instead of dropping and reestablishing data connection.
Will test the other options once I upgrade to 0.4 ril wrapper and S4 mdeejay kernel.
EDIT: oh yeah, I noticed though the default options.smd is blank, when pppd is running it creates a options1.smd in /etc/ and it has the words "user dummy" in it?
I no longer have the Samsung Focus but I keep monitoring these forums just in case I change my mind in the future.
While I had the phone I noticed that even though I had set the camera to 5 megapixel, the pictures I emailed, manually uploaded to SkyDrive or the ones that the phone automatically uploaded to SkyDrive camera roll were all severely lowered in resolution. The dimensions of these photos were reduced to 719x539. I never tried syncing the phone to my laptop via the Zune software.
I do not recall seeing anywhere a setting that would account for this severe drop in resolution. I know that when sending photos via MMS they need to be reduced in size, but I am not talking MMS.
Why were all these photos reduced in resolution? Did I miss something in setting up the phone?
It is done so to save your cell data usage. From what I hear, there should be an option to upload full-res phone but never tried.
foxbat121 said:
It is done so to save your cell data usage. From what I hear, there should be an option to upload full-res phone but never tried.
Click to expand...
Click to collapse
If that is so, nice to see that whoever decided this thinks about the consumer, but ultimately the choice should be yours not Microsoft's. Let the user take advantage of that 5 megapixel camera. Not much different than Microsoft's decision to not support hidden WiFi networks and the lame reasoning behind that.
If there is a setting to allow full res uploads, great. I haven't seen it though, but of course it wouldn't be the first time I overlooked something. But I did look for it and could not find it. If this setting is available thru one of the diagnostics codes, that is not acceptable.
Most likely using Zune would allow full resolution. I just never go to trying it. But even so, personally I want to be as much self sufficient as I can without constantly needing a laptop or desktop.
Think of this way: photos uploaded to the cloud are intended to be used by web viewing. Full-res 5MP photo is just a waste of time and resource in this intended purpose. I think Microsoft did the right decision here. As with most of the features in WP7, they are what they are for the practical usage of that feature for majority of the consumers without the need to tweak it. Most ppl today has a limited data plan, it won't be too many pictures before they use up their 2GB data cap or worse, 200MB. Remember once the upload feature is turned on, it will automatically upload every picture you take. Imagine you forget that and used up all your data caps in a day when you take loads photos for your kid.
Hey guys i was looking arroun xda and stumbled appon this. http://forum.xda-developers.com/showthread.php?t=1961353.
EDIT: TESTED DOES NOT WORK!!
It says it
-Increase internet speed (EDGE, 3G, WLAN, VPN). Works with all browsers including Opera with all APNs.
- Compressing pages and then decompressing for less data usage & smooth browsing.
- Bypass slow downloads and let you full speed downloads from some file sharing site which requires premium account for fast downloads. Like depositfiles etc.
- Boosting network signal strength so to have no call drops.
Click to expand...
Click to collapse
I have been running iy for about 7 hours now, and have to say that it does do some of what it claims.
3g speed seems to have increased and remain steady at over 1mbps. However wifi (wlan) seems no faster but no worse either. I did not test vpn as i do not have one setup.
The browser compression also seems to work, as pages load quicker. It also seems the whole page loads all at once instead of piece by piece.
The full speed downloads dosent seem to work, at least not from depositfiles.
The network signal boot also dosent work, as my db's are the same as usual, high 80s to low 90s.
Even though several things dont seem to work, they dont break anything either. I think just for the 3g tweak and browser compression, it is worth it. Also i know it says for android 2.3.6+, but works fine on 2.3.4.
I don't expect much from these type of tweaks and think they're more placebo than anything. There's nothing on the ROM side that can improve signal.
Browser compression sounds like an interesting idea. If you're familiar with the protocol rsync, it can use compression to transfer and use less bandwidth. However, I haven't heard of compression remote webpages prior to sending them which is really the only way this would logically work. That doesn't mean it doesn't exist.
The 3g speed tweak I'm also wary of. I think it may be placebo as network speeds vary and Verizon can already achieve 1mbps+ on their network.
As far as the bypassing slow downloads, that's definitely possible; however, it sounds wrong.
The only differences between Android 2.3.6 and 2.3.4 are a few bug fixes.
Edit: A little extra feedback after viewing the script.
I don't think any of the service lines will actually work as some of these look designed for init.rc, not init.d which is shell scripts.
As far as the network signal strength booster, it calls a legacy device script (goldfish which is the emulator and not a real device).
Not sure about the speed tweaks or slow download bypassing.
tiny4579 said:
I don't expect much from these type of tweaks and think they're more placebo than anything. There's nothing on the ROM side that can improve signal.
Browser compression sounds like an interesting idea. If you're familiar with the protocol rsync, it can use compression to transfer and use less bandwidth. However, I haven't heard of compression remote webpages prior to sending them which is really the only way this would logically work. That doesn't mean it doesn't exist.
The 3g speed tweak I'm also wary of. I think it may be placebo as network speeds vary and Verizon can already achieve 1mbps+ on their network.
As far as the bypassing slow downloads, that's definitely possible; however, it sounds wrong.
The only differences between Android 2.3.6 and 2.3.4 are a few bug fixes.
Click to expand...
Click to collapse
The browser compression and 3g seem to work, pages load faster and seem snappier. I know vzw is capable of 1mbps, but i rarley ever got half that before the tweak. Now i get it consitentlty at all times of the day. I dont think its placedo, and the the poll on that thread suggest people are happy with it. Its worth a shot if you have some free time. And its easy to remove if you dont like it, just delete 2 files and a folder
cmlusco said:
The browser compression and 3g seem to work, pages load faster and seem snappier. I know vzw is capable of 1mbps, but i rarley ever got half that before the tweak. Now i get it consitentlty at all times of the day. I dont think its placedo, and the the poll on that thread suggest people are happy with it. Its worth a shot if you have some free time. And its easy to remove if you dont like it, just delete 2 files and a folder
Click to expand...
Click to collapse
Try running it from the terminal or adb shell by doing sh init.d script name and I'm pretty sure it will bomb out on you like it did for me. I tried the bottom one and the second attachment from the OP there.
Below is my error:
Code:
[email protected]:/storage/sdcard0 # sh netforks_tweak
netforks_tweak[12]: syntax error: '(' unexpected
tiny4579 said:
Try running it from the terminal or adb shell by doing sh init.d script name and I'm pretty sure it will bomb out on you like it did for me. I tried the bottom one and the second attachment from the OP there.
Below is my error:
Code:
[email protected]:/storage/sdcard0 # sh netforks_tweak
netforks_tweak[12]: syntax error: '(' unexpected
Click to expand...
Click to collapse
Lol, never even thought of trying that. Your right i het the same error. The init-goldfish.sh file that the init.d script runs also fails on execution, but that is a stock system file. I wonder why my 3g speeds are better? Im getting double what i usually get, and its actually consistent and not bouncing all over the place. Mabey vzw put up a new tower or something. And i guess with increased speed the browser would seem snappier. Oh well thought i stumbled on something cool, but its just garbage i guess. Thanks for clearing it up tiny.
cmlusco said:
Lol, never even thought of trying that. Your right i het the same error. The init-goldfish.sh file that the init.d script runs also fails on execution, but that is a stock system file. I wonder why my 3g speeds are better? Im getting double what i usually get, and its actually consistent and not bouncing all over the place. Mabey vzw put up a new tower or something. And i guess with increased speed the browser would seem snappier. Oh well thought i stumbled on something cool, but its just garbage i guess. Thanks for clearing it up tiny.
Click to expand...
Click to collapse
According to the dev, the ( error is ok.
So, if you want to test it again to verify, type getprop and see if anything shows from the tweaks script as far as the setprop lines. I have a feeling nothing will but I want to validate 100% that this doesn't work.
I've done some testing on my own by making shell scripts and confirming an error should not bomb out the whole script but just abort at the point of the error.
But really, this thing does nothing, even zeppelinrox shot it down.
tiny4579 said:
According to the dev, the ( error is ok.
So, if you want to test it again to verify, type getprop and see if anything shows from the tweaks script as far as the setprop lines. I have a feeling nothing will but I want to validate 100% that this doesn't work.
I've done some testing on my own by making shell scripts and confirming an error should not bomb out the whole script but just abort at the point of the error.
But really, this thing does nothing, even zeppelinrox shot it down.
Click to expand...
Click to collapse
No nothing from the script shows in getprop. I would say the whole things a bust.
I'm using a USB MIDI keyboard (through a mini USB connector) and trying to use my Galaxy S4 to drive the sound. The reason is that it's a small, portable, solid state computing device (stage vibrations already killed a couple hard drives in the last few months) that I already own. The drawback, of course, is latency. The delay between key press and sound generation makes this unworkable.
Here's a list of what I've done, I'd love to hear any advice for making this possible. I'm hoping to update this into a complete tutorial if it is successful:
1) The best app as far as sounds available (for the music I play, this may vary for you) AND allowing external keyboard control is Music Synthesizer (https://play.google.com/store/apps/details?id=com.levien.synthesizer). It would be ideal if there was an app that allowed VST plugins for custom sounds or had its own internal latency controls, but none seem to exist on Android. Please, please notify me if I'm wrong. That would make this whole setup better.
2) Because stock Android is super bloated, I wiped and flashed TriFroceRom onto my device using TWRP. This was harder for me than I'd like to admit, so allow me to point future people to what worked for me:
First you'll need to get TWRP up and running. Here's the walk through that worked for me: http://wccftech.com/install-twrp-recovery-on-samsung-galaxy-s4-i9505/
This is the best tutorial I've found for installing TriForce: http://wccftech.com/flash-triforcerom-54-samsung-galaxy-s4-sphl720/. MAKE SURE you do not just reboot straight away. Follow that last step about going back to home, reboot menu, into system. And it may ask to fix your root permissions too. I skipped that part and had a dead phone for a while.
Also, if you're on this stage and wondering about the best way to back everything up before you do it, G Cloud (https://play.google.com/store/apps/details?id=com.genie9.gcloudbackup&hl=en) is your answer. It is free, works perfect on upload and download, and lets you look at what is on their server at any time (including browsing photos, not just file names). Text messages and contacts sync too. If you pay a little bit of money for the full version, it will even keep your application data. If you're super cool and want to put in my referral number, it's BG2III (gives me more storage, and those are uppercase letter i not number 1s).
3) I then added Ktweaker so that I could overclock and improve the system performance. I watched this video to figure it out: https://www.youtube.com/watch?v=w5hcuLG-xp0. He has a link to download the files for Ktweaker which is this: http://forum.xda-developers.com/showthread.php?t=2294083 but you ALSO need to know that, with the links provided, you PROBABLY need 4.3 touchwiz version. TriForce Rom is a touchwiz rom for sure, and depending on when in the future you see this, check your device's about page (in the settings on your phone) to make sure which version of android you're running.
ALL OF THIS SAID, I have noticed zero improvement. I've read some documentation on Ktweaker and watched some videos on optimizing it and tried several different settings (overclocking, changing the CPU governor, reducing internal and external read ahead (and increasing, for kicks and giggles, though it seemed counter to my intuition), and ultimately have found not a single detectable millisecond of improvement in the latency.
Does anybody have any ideas? I understand that the Nexus devices are supposed to have lower latency, but a new device is not currently in my budget. It seems to me that MIDI controllers have been possible with very low latency since far before the computing power of even this phone was available, so conceivably there should be a way.
deleted
OK, since I have been digging and fighting issues with my 2nd hand Note 8.0 for testing with KK, I stumbled upon a quick and dirty way to fix AllShareCast once and for all.
Search on the main search bar for S5 libs... there are S5 4.4.2 build Apps you can download as a zip package.
Once you open it you will see all the Allshare.apk and odex files.
Just rename your originals before copying over the 14 in total, S5 versions. Set the permissions and clear the Allshare files in cache, before rebooting.
You can also copy over the two wfd files for a nicer look for allshare connection.
I decided to revert to stock SystemUI to take advantage of the 6 button setup. Low and behold I get S finder and Quick Connect as well when you change the build.prop to use S5 model and name, instead of the ones used for Note 8.0 properties.
Enjoy stutter free wireless video casting with the S5 files.
gooberdude said:
OK, since I have been digging and fighting issues with my 2nd hand Note 8.0 for testing with KK, I stumbled upon a quick and dirty way to fix AllShareCast once and for all.
Search on the main search bar for S5 libs... there are S5 4.4.2 build Apps you can download as a zip package.
Once you open it you will see all the Allshare.apk and odex files.
Just rename your originals before copying over the 14 in total, S5 versions. Set the permissions and clear the Allshare files in cache, before rebooting.
You can also copy over the two wfd files for a nicer look for allshare connection.
I decided to revert to stock SystemUI to take advantage of the 6 button setup. Low and behold I get S finder and Quick Connect as well when you change the build.prop to use S5 model and name, instead of the ones used for Note 8.0 properties.
Enjoy stutter free wireless video casting with the S5 files.
Click to expand...
Click to collapse
you should packages all apps, libs into zip file and share it with rest of users....
Here is a zip of the allshare files he was talking about. I only found 13 though. I also included the wfd files he talked about.
Dirty fix without replacing files.
Thanks for both of your replies... Jazzespresso, I am not a developer and because of it, I think the peeps who frequent here find my posts interesting for thought for the most part. I have two issues to why I am not active in posting my personal fixes as packages. One, too many find issues to why something may break and will expect expertise. The later is I have yet to make a proper package, as every backup I make on the 4.4.2 device soft bricks the device once flashed. So, if any thing being snake bit by my own hand makes me even more shy about giving out anything that I touch upon in making changes.
Now for a great addition to tweaks for the best image quality and playback with allsharecast.
I perposfully made this wordy, so if anyone should attempt, will be informed of what this tweak does and have an understanding of what it affects and how to assess what they are doing. Remember, I did not tell you to do anything, just gave you enough to look into what can be done.
Because I have no ability to push beyond 72mbs on my wireless router with my tablet, I have a limit to how smooth my allshare up and video down streams can work together. I am bottle necked at 40000000 bps with allsharecast. So I would assume 30000000 bps is at the edge of my video downstream with 90 % of the apps I use.
Until recently I checked out Directv sports streaming via allsharecast, and noticed how choppy and blurry it was. Obviously when pushed at the limits of my wireless router connection, audio only would play back or no connection what so ever. Directv live streaming seems mostly effecting sports not programmes or ads in the sports channels.
I figure the live material is true 720p @ 60fps, which taxes the abilities to allsharecast. The device is native 30fps on both HDMI and Allshare, so it has to do twice the work to make an image. Now for the kicker. Directv throttles stream directly, so no caching of data for you. Since the CPU/GPU has to throttle along with the data stream there is a sync delay being made during the process, in which allsharecast cannot work around. The only work around is to push very close to 2x the data as it is factory set for.
Why so much data... Well because you want allsharecast to take what is given by the app to decode into live packets without having to readjust the image to compensate for higher than expected data rates. Each resolution has a specific data rate to transmit or cast out to the WIDI display device. You will see that in the WFDConfig.xml file... that depending on the device that is connected via allsharecast will allow a particular data stream, governed by an option bit. The option bit or bits will select the maximum and any other data stream that it can handshake. The funny thing is, since android does not request the exact min / max values from its connection, it gives a best guess depending on the option bits it reads from the device, as it expects the device to be compliant. Are all devices compliant??? Coming from China and what not... No.
Because most do not know the capabilities of their wireless display adapters or devices, it will be random at best for them to select which area to tweak to allow a higher than maximum value in the xml file. Thus one must perform a shot gun method of hitting as many possible valid settings at once. Leaving the low bit rate values alone as they are a waist to deal with. Though there is a catch... some devices may have odd bits, that do not reflect their capabilities to android, so android may make the wrong guess and push a lower quality bit rate than what the device can deal with. Or in worst case, higher than what the device can operate with, and get no picture or fail to connect display after obtaining IP.
Now that that info has been stated, if by change during the tweak, you find the picture quality less than expected or no connection... that the changes you made must be changed to compensate for going the wrong way.
Now what can be done, as we all think data is compressed all the time, in allshare, WIDI and what other format, the data stream is uncompressed unlike the data stream sent from the servers. It all depends on ones dongle, tellie, or display with miracast capabilities may not have the ability to go beyond 45000000 mbs. Only testing can be done with what ever device you own.
I tested my dongle as it is HDMI 1.4a compliant, and found for a brief moment I was pushing 50000000, until the download stream failed to cache enough for playback. So until I am able to replace my 10 year old DSL wireless router that is being used as a gateway to my DOCSIS modem, I will never be able to test the limits of what my tweaks can do.
I will give only giving out the settings I am using, and not the file as it is modified to the point of being of use for only one of many various Miracast dongles you can find on Ebay. All I can say about the dongle is that it uses the latest firmware (V 5.0.0 - RC2) which I was able to download and flash.
I have realized every app that streams video from the internet uses different streaming techniques and perform stream caching on their own, while others allow Android to perform the task of data caching. As we see more efforts in making faster and larger data packets in streams, we'll see more and more play back issues with KK and LP because newer techniques are expecting real-time decompression during playback. Probably due to copy write protection, as the data is not stored in any way.
In order to fully test my allshare tweaks for KK, you must remove or # any and all build.prop tweaks associated with data and wifi tweaks. Also freeze or remove any app that helps with internet speeds.
Once you are done cleaning up... open the WFDConfig.xml file in the system/etc folder.
If using a device with native 800 x 1280 display make sure the Horizontal res and vertical res is set at 1280 and 720 respectfully. There is no reason why you want Allsharecast to upscale to the default of 1920 x 1080 when all it does is consume battery and cpu / gpu resources to make the best playback possible. This will allow for smooth and reliable wireless display playback under the most demanding material or live streams.
Now for the fun part... meaning you must do the dirty work of finding where to go or just change everything in regaurds to minimum and maximum values ... blah blah blah
I played with drop frame value and others... the only noticeable benefit being limited with my max bandwidth of 72mbs, was to disable MacroBlocks by setting it to 0. This helps a lot with data streams that are not cached.
Now for the values that will boost image quality.
I have successfully tested connectivity and playback with a 30000000 bps MinBitrate and am limited at 40000000 bps at MaxBitrate.
Right now the bigest trouble is with Hulu studdering with movie playback. Once that is corrected with a better app, allshare cast will play back what you see on the tablet screen. I think once someone tests with at least 75000000 bps as MaxBitrate with a 50000000bps MinBitrate, as long as their device can support 80000000 bps and above, Directv will allsharecast without any issues. As seen in my testing, playback via wireless has cleared up substantially, and can watch Hocky and Tennis with synced audio, as before it was not able to. Though there is some skippy and blur, the playback is functional over being unbearable.
Any help would be greatly appreciated. When copying over files from above zip, (thanks cruise350) to system/app folder and replacing allshare files with one in above zip, where do i place the additional odex files?
christucker97 said:
Any help would be greatly appreciated. When copying over files from above zip, (thanks cruise350) to system/app folder and replacing allshare files with one in above zip, where do i place the additional odex files?
Click to expand...
Click to collapse
At the time I posted this thread, realized the S5 files helped with allsharecast, but does not truly fix the issue. That is why I bothered to write up a lengthy explanation to fix most of all share cast's picture quality issues.
Until someone see's by doing their own comparison between DLNA and casting, they will not see for themselves how limited the stock bandwidth is, which also effects playback when casting streamed video.
I since reverted back to my original allshareplayer-apk as it seems to be bandwidth unlocked. Now will it be a matter of time when others find using our kk version on their s5 helps them when tweaking their XML file. Who knows, as this tablet is old and will be forgotten for most who have newer devices.
Does files belong with their counter parts. So you must replace both files together.
I do note, that one set of files are the same for both devices.
If you want to keep your WiFi tweaks you may replace the all share player.apk with the s5 version. If you want better, keep the original, and tweak the XML file. Until you properly adjust e XML file, you will never get picture quality as good as DLNA with streamed hd video.