Related
Hello All,
I just upgraded to the last WM6 (really cool OS btw)
I've been going through the treads but I can't find a solution for my stupid problem.
I can't set up my old ringtone, before I just needed to past the in the "\Application Data\Sounds" directory and I could select them as ringtones or custom ringtones.
But since the WM6 they don't appear anymore in the options.
I copied them everywhere
- root directory of storage card,
- \My Documents\My Ringtones\
- \Storage Card\My Documents
But they still don't appear what am i doing wrong?
I have 2 MP3 files that worked fine on my WM5
Thanks in advance.
Frem
Which WM6 ROM are you using?
But then, I am able to select custom MP3 ringtone for all builds of WM6
Version :
OS 5.2.318 (Build 15341.0.0.1)
Are they Mp3 format and what is the directory where you put them?
I just put some .WMA custom windows ringtones in the "\Application Data\Sounds" and they appear ! Is it that .mp3 are not recognized under WM6?
I converted my .MP3 to .WMA they now appear, but they sound TERRIBLE. How can I make the mp3 version recognized ?
Just put your ringtones to root of your storage card.
Have you tried sticking them in \windows\rings?
well I did put them in all those folders. But the mp3 versions don't appear.
The .wma do appear though.
For some unknown reason the phone doesn't see the mp3 versions.
Who's ROM are you using? Phil or Andot ?
I'm not sure I used the one from that tutorial:
http://karhoe.byethost33.com/index.php?option=com_content&task=view&id=21
In the About I have Version:
OS 5.2.318 (Build 15341.0.0.1)
Radio Version 4.1.13.28_06.61.01
RIL Version 2.002
Rom update versions 5.2.318.15341
I don't know if it's Phil's or Andot's.
Can you figure out which version I have from the info I gave you? And what is the best version?
Lol I just realized the tutorial I used is the same one as your signature . I guess you have the answer then.
Your guide is really good, I did the upgrade yesterday, and it took me 50 minutes to get everything set up on my Qtek 8310.
Very good job.
I'm still dealing with this mp3 file ringtone issues though .
Probably Andot's. I have the same problem and I'm using Andot's. Thanks for the fix.
I'll dig around in the registry and search for "\Application Data\Sounds" and see if it got mucked up some how...
Yeah my work-around with the .WMA convertion works.
I was able to get a decent sound with a .WMA version of my .MP3 version so I'll survive .
But still I like when things are perfect and are like they used to be, and even better.
So far this WM6 as make everything faster, easier, better, software more stable and some didn't work before or made the phone crash like PMrecorder, now it works perfectly.
I feel like having a new phone even if it's like 2 years old hehe.
Ok very weird I put an other MP3 which is 217K, it's smaller than the other mp3s I tried (496kb and 398kb) And this one appear!!!
It could be size related. We could do some checkup is the registry and test in that area.
frem said:
Ok very weird I put an other MP3 which is 217K, it's smaller than the other mp3s I tried (496kb and 398kb) And this one appear!!!
It could be size related. We could do some checkup is the registry and test in that area.
Click to expand...
Click to collapse
Strange. I'm test right now - tried mp3 file 863 KB and its OK. May be bit rate?
I'm use 128 kbps.
The two that don't appear have those settings :
-----------------------------
Size: 406802 bytes
Length: 25 seconds
MPEG 1.0 layer 3
128kbit, 975 frames
44100Hz Joint Stereo
-----------------------------
Size: 507112 bytes
Length: 32 seconds
MPEG 1.0 layer 3
128kbit, 1216 frames
44100Hz Joint Stereo
-----------------------------
The one that appear has this setting :
-----------------------------
Size: 223184 bytes
Length: 56 seconds
MPEG 2.0 layer 3
32kbit, 2146 frames
22050Hz Mono
-----------------------------
So the diffrence between the files are
- MPEG 2.0 layer 3 / MPEG 1.0 layer 3
- 32kbit / 128kbit
- 44100Hz / 22050Hz
- Mono / stereo
The problem is related to one of those parameters.
If i understand your last post you said that your 128kbit version appeared so we can remove that parameter. Is your 128kbit file that appear encoded in
- MPEG 2.0 layer 3 or MPEG 1.0 layer 3 (the info appear in winamp file info)
- Is it mono or stereo?
- What is the Hz on that file that appear?
We will get to the bottom of this !
OK. First file:
Payload Size: 879804 bytes
Header found at: 4096 bytes
Length: 55 seconds
MPEG-1 layer 3
128kbit, approx. 263 frames
44100Hz Mono
CRC: No, Copyrighted: No
Original: Yes, Emphasis: None
Second:
Payload Size: 883672 bytes
Header found at: 417 bytes
Encoder Delay: 576, Zero Padding: 1728
Length: 52 seconds
MPEG-1 layer 3
136kbit (VBR), 1994 frames
44100Hz Joint Stereo
CRC: No, Copyrighted: No
Original: Yes, Emphasis: None
Third:
Payload Size: 2975869 bytes
Header found at: 0 bytes
Length: 186 seconds
MPEG-1 layer 3
128kbit, approx. 889 frames
44100Hz Joint Stereo
CRC: Yes, Copyrighted: Yes
Original: Yes, Emphasis: None
And two small files:
Payload Size: 484075 bytes
Header found at: 4258 bytes
Length: 30 seconds
MPEG-1 layer 3
128kbit, approx. 144 frames
44100Hz Mono
CRC: Yes, Copyrighted: No
Original: No, Emphasis: None
Payload Size: 323848 bytes
Header found at: 0 bytes
Length: 20 seconds
MPEG-1 layer 3
128kbit, approx. 96 frames
44100Hz Mono
CRC: Yes, Copyrighted: No
Original: No, Emphasis: None
All this files works fine! I can assign all of them like ring tone.
I'm using Andot last (V6) ROM.
Exitao said:
Probably Andot's. I have the same problem and I'm using Andot's. Thanks for the fix.
I'll dig around in the registry and search for "\Application Data\Sounds" and see if it got mucked up some how...
Click to expand...
Click to collapse
Well like Exitao said i'm probably using Andot's as well i used the ROM from karhoe's tutorial :
http://karhoe.byethost33.com/index.php?option=com_weblinks&task=view&catid=20&id=29
I tried some high quality mp3s files as well and they appeared
Size: 5405593 bytes
Header found at: 0 bytes
Length: 225 seconds
MPEG 1.0 layer 3
192kbit, 8635 frames
44100Hz Stereo
CRCs: No
Copyrighted: No
Original: Yes
Emphasis: None
So the only files that didn't appear have those settings:
----------------------------------
Size: 507112 bytes
Header found at: 0 bytes
Length: 32 seconds
MPEG 1.0 layer 3
128kbit, 1216 frames
44100Hz Joint Stereo
CRCs: No
Copyrighted: No
Original: Yes
Emphasis: None
----------------------------------
Size: 406802 bytes
Header found at: 0 bytes
Length: 25 seconds
MPEG 1.0 layer 3
128kbit, 975 frames
44100Hz Joint Stereo
CRCs: No
Copyrighted: No
Original: Yes
Emphasis: None
------------------------------------
I just did a test on the second one (25 sec) that wasn't working. I re-encoded it with those settings:
Size: 509516 bytes
Header found at: 0 bytes
Length: 25 seconds
MPEG 1.0 layer 3
160kbit, 976 frames
44100Hz Joint Stereo
CRCs: No
Copyrighted: No
Original: Yes
Emphasis: None
And now it works it appear!
And if we check all the settings it makes absolutely no sense . Ho well one of those mystery bug .
I guess if it happens to someone else we can only advice him to re-encode his file and that will fix it.
Thank you for your help.
Frem
OK. Good to see what all working!
Got to let Phil now, hopefully he can fix this up
Why Phil? I thought i had Andot's ROM from your tutorial?
Andot is not really developing Tornado nowadays, but his wife's Typhoon
Nvidia lists the following specs on their website for the Tegra2 :
Video decode
H.264
VC-1 AP
MPEG2
MPEG-4
DivX 4/5
XviD HT
H.263
Theora
VP8
WMV
Sorenson Spark
Real Video
VP6
Audio decode
AAC-LC
AAC+
eAAC+
MP3
MP3 VBR
WAV/PCM
AMR-NB
AMR-WB
BSAC
MPEG-2 Audio
Vorbis
WMA 9
WMA Lossless
WMA Pro
Can anyone confirm that the xoom can decode these?
Can the Xoom/honeycomb media player read subtitles (in) .mkv or .srt, sub/idx files?
The xoom can handle those, but only very specific versions of those. For example, don't try playing a 720p high profile h.264 video, because it won't play. So if you torrented a 720p video for example and it was an mkv file, not gonna play since they are almost all high profile h.264. You can convert them to baseline h.264 and it will play up to 1080p, but converting is annoying and takes time.
I am not sure what is out there on torrents, but I have some MKVs that I encoded and they have a bitrate of around 3mbit. According to this general tips section:
http://forum.xda-developers.com/showthread.php?t=969029&highlight=720p
The Xoom is supposed to be able to play video as long as the bitrate is under 20Mbit. The post references this:
https://supportforums.motorola.com/message/330326#330326
which says that realistically as long as the bitrate is under 4Mbit you should be fine.
The MKVs that I am trying to play, which are well under 20mbit and under 4mbit, skips like crazy and is unwatchable.
If I look at vmstat (via adb shell) while I am playing a movie using rock player in software decoding mode, the CPU goes to 100% (presumably in the kernel that android is using each core gets 100%, so there is a total of 200% available -- half ends up in system and half in user land):
procs memory system cpu
r b free mapped anon slab in cs flt us ni sy id wa ir
2 0 74440 58584 254928 30112 158 1005 0 99 0 30 99 0 0
1 0 74564 58588 255036 30124 466 2263 0 99 0 22 99 0 0
1 0 68392 58880 261072 30128 367 2742 0 99 0 32 99 0 0
1 0 67136 58968 262216 30180 684 3604 0 99 0 32 99 0 0
2 0 67004 58976 262456 30180 224 1635 0 99 0 13 99 0 0
3 0 66632 58912 262756 30180 272 1721 0 99 0 10 99 0 0
3 0 60564 59724 266896 30160 414 2212 3 99 0 19 99 1 0
3 0 25136 60136 294812 30196 603 3372 0 99 0 76 9 0 0
4 0 25012 60128 294512 30184 472 2458 0 99 0 88 6 0 0
5 0 25020 60128 294448 30184 390 2121 0 99 0 99 3 0 0
3 0 24540 60128 294440 30164 265 1631 0 99 0 99 1 0 0
4 0 24416 60128 294576 30164 353 1768 0 99 0 93 6 0 0
4 0 24912 60128 293108 30140 332 1747 0 99 0 99 5 0 0
3 0 24788 60128 293076 30140 300 1604 0 99 0 99 3 0 0
While looking at hardware decoding mode, the system usage drops way down:
procs memory system cpu
r b free mapped anon slab in cs flt us ni sy id wa ir
2 0 54116 58928 262524 30140 170 933 0 99 0 10 99 0 0
3 1 63780 58932 262520 30276 1119 4809 0 99 0 24 99 6 0
7 0 50184 59544 264332 31072 3493 19967 6 99 0 99 98 14 0
4 0 5620 59852 311776 31124 455 4765 2 99 0 61 18 0 0
3 0 5124 59868 311872 31064 368 4590 0 99 0 33 23 0 0
4 0 5124 59860 313024 30952 322 4625 0 99 0 39 44 0 0
3 0 4760 59860 313060 30936 390 5172 0 99 0 45 25 0 0
3 0 5256 59860 313032 30900 358 5475 0 99 0 38 30 0 0
3 0 4884 59868 312992 30876 336 5202 0 99 0 31 35 0 0
4 0 4636 59868 312856 30816 307 5036 0 99 0 34 36 0 0
3 0 5504 59904 312876 30816 378 5095 0 99 0 36 37 0 0
4 0 5504 59912 312884 30664 363 5046 0 99 0 33 44 0 0
3 0 4512 59924 312808 30656 288 4796 0 99 0 27 29 0 0
4 0 5256 59928 312908 30408 287 4927 0 99 0 32 38 2 0
3 0 5008 59928 312808 30404 367 5779 0 99 0 44 28 0 0
1 0 5132 59944 312820 30224 490 3432 0 99 0 36 74 0 0
But the playback remains fairly choppy. So all we need is the great devs at Rockplayer to stick the right code in for hardware decoding.
Presumably the native player uses hardware decoding which is why it is able to play video with framerates around 4mbit.
http://mediainfo.sourceforge.net/en
Download that and after installing, open it up and drag your mkv file into the window. Bet you that those videos are high profile h.264 which is the reason for the choppiness.
The reasons your processor max out in software mode is that its using the CPU to play the file. It drops down using hardware acceleration because its the GPU playing the file.
I used mediainfo to get the bitrate, which is under 4Mbit, which is under the limit that is quoted on the Motorola website. The fact that they may be a specific "media profile" in whatever converter you are using makes no difference -- only the bitrate is important.
Also, as mentioned in my post, I understand that the CPU drop is due to the use of hardware rendering. We still have to wait for either specific Xoom GPU support in Rockplayer or optimized code changes in Rockplayer.
Also, it appears that the native movies app is able to play my MKV files. It plays them much smoother, but they are still too choppy and the sound doesn't come through. The audio track on this is an AC-3 48KHz, 384Kbps audio stream.
No. You dont understand. The profile is everything. Bitrate means nothing. Tegra 2 is not capable of playing high profile hd h.264. The video you are trying to play is probably a high profile h.264 mkv file. There are various profiles for h.264 video. The Tegra 2 can play baseline profile. Almost all media is in high profile.
Do this for me, drag the media file you are trying to play into MediaInfo, and then go to View>Text. Then select the entire Video section and copy it and then paste it in here.
Thanks guys.
The sad thing is a cheap single core tablet with limited memory like the Archos 101 can play any video I throw at it without needing to convert them. The Archos 101 even plays DTS and AC-3 audio. Most of my videos are 720p HD and the only thing it doesn't play is 1080p. However, the Archos 101 is not perfect.
I was really hoping that the Xoom (or one of these other tablets) could at least come close to performing as well. How is it a company like Archos can make a cheap tablet perform so well (media wise) and these higher end tablets fall short?
kmd1970 said:
Thanks guys.
The sad thing is a cheap single core tablet with limited memory like the Archos 101 can play any video I throw at it without needing to convert them. The Archos 101 even plays DTS and AC-3 audio. Most of my videos are 720p HD and the only thing it doesn't play is 1080p. However, the Archos 101 is not perfect.
I was really hoping that the Xoom (or one of these other tablets) could at least come close to performing as well. How is it a company like Archos can make a cheap tablet perform so well (media wise) and these higher end tablets fall short?
Click to expand...
Click to collapse
software, honeycomb is buggy, its hardly optimized. no one really knows what the tegra 2 is capable of yet.
the facts are simple, there no tegra 2 device capable of playing high profile h264 right now.
tegra 2 devices are just now making it to market and its new untested unproven hardware.
secondly there are only two devices released or pseudo released(in the case of the adam) that even use this hardware. not alot of info to go on here.
at this point ask anyone here and they can't give you any 100% accurate answer, because we simply don't know. its ALL speculation at this point.
you have two camps on this issue. one camp, the hardware people claim that because both the adam and xoom use tegra 2 and can't play h264 high profile that its a hardware limitation.
the second camp takes the side that because this is new hardware, it needs proper software and drivers to handle the decoding and that this is the reason for the poor playback. this camp believes it will be fixed down the line with an update.
the second camp is the more feasible scenario. anyone that knows anything about hardware and software understands that hardware is worthless without good software.
let me give a prime example everyone knows video encoding takes time. if you want to encode a 20 minute video lets say you use handbrake and encode the video using your cpu in 14 minutes. but wait, whats this? you have a $500 nvidia graphics card in your system? its a big arse paper weight right now ain't it?
lets fix that, lets get the proper software and drivers and encode that same 20 min video by offloading to this powerful gpu. done in 5 minutes.(*actually times vary based off settings and actually hardware)
get the picture?
however, this does NOT mean that the tegra 2 is without fault. it could be the hardware and its simply not capable of high profile and never will be. we simply don't know, because we don't have any good information from nvidia or motorola or notion ink. we don't know what its true capabilities are.
all we know is that the tegra 2 with the current available devices and software cannot play high profile h264.
all the rest is speculation.
..........
From an XBMC developer:
http://forum.xbmc.org/showpost.php?p=735285&postcount=41
Tegra2 can't hw decode h264 [email protected] or above. I know because I have one (Tegra2 dev kit). That really limits the video content to SD. Too bad, it's a nice chip except for that.
Click to expand...
Click to collapse
This guy worked on porting XBMC to iOS and has videos like this:
Code:
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 9 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 52s
Bit rate : 6 478 Kbps
Nominal bit rate : 5 660 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
playing like this:
http://vimeo.com/20636064
on the ipad.
Same file playing on two different Tegra 2 tablets:
http://www.youtube.com/watch?v=lXWu6m33EP0&feature=player_detailpage#t=231s
... with the amount of Tegra2 for the next month,
i think we could download all videos in tegra2 useable formats (720p/1080p) and nvidea will also adress this topic, so i am not worried about ...
muyoso said:
From an XBMC developer:
http://forum.xbmc.org/showpost.php?p=735285&postcount=41
This guy worked on porting XBMC to iOS and has videos like this:
Code:
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 9 frames
Muxing mode : Header stripping
Codec ID : V_MPEG4/ISO/AVC
Duration : 1mn 52s
Bit rate : 6 478 Kbps
Nominal bit rate : 5 660 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate : 23.976 fps
playing like this:
http://vimeo.com/20636064
on the ipad.
Same file playing on two different Tegra 2 tablets:
http://www.youtube.com/watch?v=lXWu6m33EP0&feature=player_detailpage#t=231s
Click to expand...
Click to collapse
take his with a grain of salt. all he said was i have a tegra 2 dev kit and tegra 2 can't do the high profile h264.
whats this even mean? is there something in this dev kit that actually lists what the tegra 2 is capable of hardware wise? whats in this dev kit, whats the real reason it won't play.
ill take him for his word when pigs fly out of his ass.
http://developer.nvidia.com/tegra/tegra-devkit-features
its just hardware, no magical software to be had there. which means what? hes got the same software we do.
also id like to point out that there is a VAST difference between making android support another codec so it can play a video and making android offload to the gpu using drivers. key word there folks, drivers.
back to the cuda example, two things are needed to tango. first you need the proper nvidia drivers. and secondly, you need an application designed to work with those drivers in order to have it successfully utilize the gpu. xbmc can only proved the app to interface with what exists, they can't do anything else.
ps:
al gore invented the internet.
Is there like a cut off date for peoples denial about tegra 2's shortcomings? Like a year from now when it still can't play video [email protected] h.264, will people still be claiming its a lack of software?
Davilla did massive testing of the tegra 2. You think there were drivers from apple for the ipad? No.
Look, there may be a software solution if the tegra 2's cpu is powerful enough to decode hd h.264, but there is massive evidence that it will never hardware decode that video. I think its an important enough shortcoming to inform people about and not lead them on with some promise of future software.
Sent from my SPH-D700 using XDA App
Any official info from NVidia about this H.264 high profile hardware decoding capability?
Anyone reached NVidia?
e.mote said:
Most Honeycomb tablets announced will have a Tegra2 in it, and video playback is an important component, so I'm confident the issue will be addressed, if not from Nvidia, then from a 3rd-party commercial media player like Coreplayer.
Click to expand...
Click to collapse
Please, not that Coreplayer for Android rumor again. (I've been waiting for too long)
It's not really CoreCodec's fault. Android has been a pretty fast moving target, and my guess is that Nvidia hasn't been exactly timely with software support for the Tegra2, else the VS G-Tab would've had decent playback by now.
My reading of the tea leaves is that we'll probably see CP either around the Honeycomb mass launch or a bit after. Anyway, it'll come when it'll come.
Now, VLC, I think will be a fair bit longer in coming,
http://ivoire.dinauz.org/blog/index.php?post/2011/02/02/VLC-on-Android
muyoso said:
The xoom can handle those, but only very specific versions of those. For example, don't try playing a 720p high profile h.264 video, because it won't play. So if you torrented a 720p video for example and it was an mkv file, not gonna play since they are almost all high profile h.264. You can convert them to baseline h.264 and it will play up to 1080p, but converting is annoying and takes time.
Click to expand...
Click to collapse
From Xoom office website, we know that Xoom supports AAC, H.263, H.264, MP3, MPEG-4, ACC+ Enhanced, OGG, MIDI, AMR NB, AAC+. If u want to play video on Xoom, the video format and video coding must be correct.
So I suggest u convert your MKV files to Mp4 H.264 1280*720 for playing.
I did a test, and I can't find any diffirence between 1080P and 720P, SO I recomend convert video to 720P, and the converted file size is small. therefore, u can transfer more video to Xoom.
For those use HandBrake, attachment is the [email protected] preset for playback in Tegra2
muyoso said:
The xoom can handle those, but only very specific versions of those. For example, don't try playing a 720p high profile h.264 video, because it won't play. So if you torrented a 720p video for example and it was an mkv file, not gonna play since they are almost all high profile h.264. You can convert them to baseline h.264 and it will play up to 1080p, but converting is annoying and takes time.
Click to expand...
Click to collapse
MKV is a container format, which supports holding unlimited number of video, audio, picture or subtitle tracks inside a single file, can’t be played on the Motorola Xoom. only the video format and video encoding are right, Xoom can be play it.
So, not because Xoom can't play 720P high profile h.264 video, but the video format is wrong. I suggest u convert MKV 720p h.264 video to MP4 720P H.264 for playing on Xoom.
Hi Devs, any plans to include support for the Tegra K1 soc? I just bought a Xiaomi Mipad and MXPlayer is proving to be flaky with frequent crashes and closing. It also shows strange behavior when playing back HI10p videos, the native player on the Mipad fails to play Hi10p but MxPlayer can be invoked to use HW or HW+ on the Hi10p videos. However I see colors bleeding in the video so I presume that MXplayer is forcing the Tegra K1 to play Hi10p as 8 bit h264 as the effect looks similar on my set top box.
Just an FYI for those hoping the Tegra K1 would be fast enough to play back Hi10p 1080p video in software mode it still stutters. If you need some debug logs etc then pls send me instructions to get those.
Kantana said:
Hi Devs, any plans to include support for the Tegra K1 soc? I just bought a Xiaomi Mipad and MXPlayer is proving to be flaky with frequent crashes and closing. It also shows strange behavior when playing back HI10p videos, the native player on the Mipad fails to play Hi10p but MxPlayer can be invoked to use HW or HW+ on the Hi10p videos. However I see colors bleeding in the video so I presume that MXplayer is forcing the Tegra K1 to play Hi10p as 8 bit h264 as the effect looks similar on my set top box.
Just an FYI for those hoping the Tegra K1 would be fast enough to play back Hi10p 1080p video in software mode it still stutters. If you need some debug logs etc then pls send me instructions to get those.
Click to expand...
Click to collapse
Just an update I tested Hi10p and h265 with VLC and it looks like the Tegra K1 can hw accelerate Hi10p but not h265, however both codecs @ 1080p plays smoothly with VLC on the Mipad. Devs pls update the MXplayer for the Tegra K1 soc
Ok, have narrowed down the cause of crashing and closing to the launcher. If HW+ is enabled this will happen 50% of the time. If I enable HW+ but not check the boxes for local or network play it will start the video normally in HW mode. But there is no audio and I need to manually choose HW+ mode. If it doesn't crash to the launcher then audio will play. I get regular MX player has stopped when I exit MXplayer after using HW+.
I see the same behavior for Diceplayer so assume that it also uses the same methods for hardware acceleration. VLC beta has no issues even with full acceleration and YUV color space. Devs pls look into this and if you need diagnostic or logging info we can assist as there are some MiPad owners out there that are testing this unit right now:
http://forum.xda-developers.com/showthread.php?p=54045235
Kantana said:
Ok, have narrowed down the cause of crashing and closing to the launcher. If HW+ is enabled this will happen 50% of the time. If I enable HW+ but not check the boxes for local or network play it will start the video normally in HW mode. But there is no audio and I need to manually choose HW+ mode. If it doesn't crash to the launcher then audio will play. I get regular MX player has stopped when I exit MXplayer after using HW+.
I see the same behavior for Diceplayer so assume that it also uses the same methods for hardware acceleration. VLC beta has no issues even with full acceleration and YUV color space. Devs pls look into this and if you need diagnostic or logging info we can assist as there are some MiPad owners out there that are testing this unit right now:
http://forum.xda-developers.com/showthread.php?p=54045235
Click to expand...
Click to collapse
If your video plays well in HW mode but not getting audio means the audio codec is not supported by your device.
You can enable SW audio from Settings 》 Decoder to play audio through ffmpeg. Video will be decoded by the hardware as usual.
---------- Post added at 06:14 PM ---------- Previous post was at 06:07 PM ----------
@Kantana
Use mx log collector app immediately after crash to collect the logs and attach here...!!!
That could be true since the audio is DTS which is not supported normally. However I can play back the video with audio from the system video player which implies that both video and audio are supported by the hardware.
Ok here is the first crash when HW+ has been enabled and used. When I exit Mxplayer then it will generate this crash. Logs attached
Here is the 2nd crash when HW+ has been enabled and ticked for local and network. I click on the file and choose mxplayer to play the file, it starts then crashes.
The system details for these 2 crashes:
=========================
Manufacturer: Xiaomi
Model: MI PAD
Brand: Xiaomi
Version: 4.4.2 (REL)
Build: Xiaomi/mocha/mocha:4.4.2/KOT49H/KXFCNBF2.0:user/release-keys
Kernel: Linux version 3.10.24-g5858f73 ([email protected]) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Fri Jun 27 10:07:03 CST 2014
CPU: 4 core(s) 2.22 GHz
CPU architecture: 7
CPU features: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
Board platform: tegra
Instruction set: armeabi-v7a (+armeabi)
Resolution: 1536 x 2048
Available screen size (DIP): 768 x 999 (smallest: 768)
Tablet: true
Screen size: X-Large
Density: 2.0 (320)
Font scale: 1.0
Hardware main button: false
Locale: en_US
Total memory: 1982052 kB
Free memory: 249704 kB
=========================
=========================
Manufacturer: Xiaomi
Model: MI PAD
Brand: Xiaomi
Version: 4.4.2 (REL)
Build: Xiaomi/mocha/mocha:4.4.2/KOT49H/KXFCNBF2.0:user/release-keys
Kernel: Linux version 3.10.24-g5858f73 ([email protected]) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Fri Jun 27 10:07:03 CST 2014
CPU: 4 core(s) 2.22 GHz
CPU architecture: 7
CPU features: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
Board platform: tegra
Instruction set: armeabi-v7a (+armeabi)
Resolution: 1536 x 2048
Available screen size (DIP): 768 x 999 (smallest: 768)
Tablet: true
Screen size: X-Large
Density: 2.0 (320)
Font scale: 1.0
Hardware main button: false
Locale: en_US
Total memory: 1982052 kB
Free memory: 151892 kB
=========================
Kantana said:
Hi Devs, any plans to include support for the Tegra K1 soc? I just bought a Xiaomi Mipad and MXPlayer is proving to be flaky with frequent crashes and closing. It also shows strange behavior when playing back HI10p videos, the native player on the Mipad fails to play Hi10p but MxPlayer can be invoked to use HW or HW+ on the Hi10p videos. However I see colors bleeding in the video so I presume that MXplayer is forcing the Tegra K1 to play Hi10p as 8 bit h264 as the effect looks similar on my set top box.
Just an FYI for those hoping the Tegra K1 would be fast enough to play back Hi10p 1080p video in software mode it still stutters. If you need some debug logs etc then pls send me instructions to get those.
Click to expand...
Click to collapse
I am in the same problem,Mipad,the system player is ok to run the video,but with MX,the HW+ mode usually crashed,when using HW mode,there is a chance the audio have problem,I need to use the SW mode for the audio.
I checked the video type that have the HW+ and no audio problem,they are H264 and AC3,strange thing is that some other video in the same type is ok to run with HW+ Mode,i am sure the video itself is no problem,i have checked it with my nexus 7 PAD.
Maybe it is the system's problem
07-10 20:52:55.872 12496 12679 F libc : invalid address or address of corrupt block 0x731648e8 passed to dlfree
07-10 20:52:55.872 12496 12679 F libc : Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 12679 (.videoplayer.ad)
On both logs there is a fatal error from libc
@bleu8888
Can you look at the issue?
---------- Post added at 01:01 AM ---------- Previous post was at 12:30 AM ----------
@kantana @donkeyear
I have discussed with the developer about your issue.
As I said libc fatal error may be due to a compiler error.
In another device we had similar crashing which is fixed in the latest test build by using the latest compiler.
Can you test the latest test build from the following link & report here. It will be helpful to resolve the issue.
https://sites.google.com/site/mxvpen/translation/test-build
ktsamy said:
07-10 20:52:55.872 12496 12679 F libc : invalid address or address of corrupt block 0x731648e8 passed to dlfree
07-10 20:52:55.872 12496 12679 F libc : Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 12679 (.videoplayer.ad)
On both logs there is a fatal error from libc
@bleu8888
Can you look at the issue?
---------- Post added at 01:01 AM ---------- Previous post was at 12:30 AM ----------
@kantana @donkeyear
I have discussed with the developer about your issue.
As I said libc fatal error may be due to a compiler error.
In another device we had similar crashing which is fixed in the latest test build by using the latest compiler.
Can you test the latest test build from the following link & report here. It will be helpful to resolve the issue.
https://sites.google.com/site/mxvpen/translation/test-build
Click to expand...
Click to collapse
No luck, still crashing randomly with test build. If HW+ is enabled it's crashing 50% of the time. It looks stable with HW+ off but sometimes no sound even with files where the audio codec is supported in hardware eg mp3 or ac3. When I enable HW+ then same random crashing.
Kantana said:
No luck, still crashing randomly with test build. If HW+ is enabled it's crashing 50% of the time. It looks stable with HW+ off but sometimes no sound even with files where the audio codec is supported in hardware eg mp3 or ac3. When I enable HW+ then same random crashing.
Click to expand...
Click to collapse
I have already conveyed this issue.
We had same issue when Tegra 3 was released. But, even NVidia people where unable to fix. Finally it was fixed by a volunteer on ffmpeg.
The developer will try to resolve the issue as soon as possible....!!
Till that use SW audio by default if you are encounter audio issues in HW mode
---------- Post added at 01:38 AM ---------- Previous post was at 01:36 AM ----------
@Kantana
Can you collect a log when you face audio issue in hw mode?
ktsamy said:
I have already conveyed this issue.
We had same issue when Tegra 3 was released. But, even NVidia people where unable to fix. Finally it was fixed by a volunteer on ffmpeg.
The developer will try to resolve the issue as soon as possible....!!
Till that use SW audio by default if you are encounter audio issues in HW mode
---------- Post added at 01:38 AM ---------- Previous post was at 01:36 AM ----------
@Kantana
Can you collect a log when you face audio issue in hw mode?
Click to expand...
Click to collapse
Hi ktsamy, here are the logs from playing a video in HW mode with no audio:
=========================
Manufacturer: Xiaomi
Model: MI PAD
Brand: Xiaomi
Version: 4.4.2 (REL)
Build: Xiaomi/mocha/mocha:4.4.2/KOT49H/KXFCNBF2.0:user/release-keys
Kernel: Linux version 3.10.24-g5858f73 ([email protected]) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Fri Jun 27 10:07:03 CST 2014
CPU: 4 core(s) 2.22 GHz
CPU architecture: 7
CPU features: swp half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt
Board platform: tegra
Instruction set: armeabi-v7a (+armeabi)
Resolution: 1536 x 2048
Available screen size (DIP): 768 x 999 (smallest: 768)
Tablet: true
Screen size: X-Large
Density: 2.0 (320)
Font scale: 1.0
Hardware main button: false
Locale: en_US
Total memory: 1982052 kB
Free memory: 151352 kB
=========================
Format : Matroska
Format version : Version 2
File size : 2.18 GiB
Duration : 44mn 1s
Overall bit rate : 7 084 Kbps
Encoded date : UTC 2012-10-11 10:07:06
Writing application : mkvmerge v2.9.0 ('Moanin'') built on May 22 2009 17:46:31
Writing library : libebml v0.7.7 + libmatroska v0.8.1
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : Yes
Format settings, ReFrames : 5 frames
Codec ID : V_MPEG4/ISO/AVC
Duration : 44mn 1s
Bit rate : 6 439 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.291
Stream size : 1.94 GiB (89%)
Writing library : x264 core 128 r2216 198a7ea
Encoding settings : cabac=1 / ref=5 / deblock=1:-1:-1 / analyse=0x3:0x113 / me=umh / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=12 / lookahead_threads=2 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=2 / b_bias=0 / direct=3 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=23 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=2pass / mbtree=1 / bitrate=6439 / ratetol=1.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / cplxblur=20.0 / qblur=0.5 / vbv_maxrate=50000 / vbv_bufsize=50000 / nal_hrd=none / ip_ratio=1.40 / aq=1:1.00
Language : English
Default : Yes
Forced : No
Audio
ID : 2
Format : AC-3
Format/Info : Audio Coding 3
Mode extension : CM (complete main)
Format settings, Endianness : Big
Codec ID : A_AC3
Duration : 44mn 1s
Bit rate mode : Constant
Bit rate : 640 Kbps
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 KHz
Bit depth : 16 bits
Compression mode : Lossy
Stream size : 202 MiB (9%)
Language : English
Default : Yes
Forced : No
It looks like an issue of hw+ decoder.
I ordered a MiPad and now waiting.
bleu8888 said:
It looks like an issue of hw+ decoder.
I ordered a MiPad and now waiting.
Click to expand...
Click to collapse
Well this has taught me to not take anything for granted with chinese tablets. They appear to have so many bugs on release and not subtle ones but major functions. You'll have a ball working around all these oversights. I'm quite pleased with the Mipad subject to them fixing these bugs.
Kantana said:
Well this has taught me to not take anything for granted with chinese tablets. They appear to have so many bugs on release and not subtle ones but major functions. You'll have a ball working around all these oversights. I'm quite pleased with the Mipad subject to them fixing these bugs.
Click to expand...
Click to collapse
> Well this has taught me to not take anything for granted with chinese tablets.
Understatement of the year
Still, per your original post, it's kinda disappointing to hear that the Tegra K1 doesn't have enough power to play Hi10p 1080p with SW mode.
I looked at the K1's specs sheet, and with a quad core A15 2.3Ghz, I would have thought for sure it was enough power...
CDB-Man said:
> Well this has taught me to not take anything for granted with chinese tablets.
Understatement of the year
Still, per your original post, it's kinda disappointing to hear that the Tegra K1 doesn't have enough power to play Hi10p 1080p with SW mode.
I looked at the K1's specs sheet, and with a quad core A15 2.3Ghz, I would have thought for sure it was enough power...
Click to expand...
Click to collapse
It's hard to tell until devs update their apps to optimize for the Tegra K1. Software is never optimal for high bitrates. The Hi10p I am testing is 7.2Mbit/s average but in certain scenes it goes over 10Mbit/s. MXplayer and Dice player are for sure using software, if I invoke HW+ mode it speeds up but I see color blotches all over the picture similar to when playing Hi10p on unsupported hardware or codecs.
VLC beta I have it all set for hardware acceleration and the playback is perfect but the amount of heat generated and battery drain leads me to suspect it is only partially accelerated.
Once the devs optimize for the Tegra K1 we'll have a clearer picture on the capabilities of the Tegra K1.
As an aside even with h265/HEVC it was easier to play smoothly since lower bit rates:
Format : Matroska
Format version : Version 1
File size : 824 MiB
Duration : 43mn 29s
Overall bit rate : 2 649 Kbps
Writing application : DivXMKVMux 9.8.10.8454
Writing library : libDivXMediaFormat 4.0.0.0578
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Codec ID : V_MPEGH/ISO/HEVC
Duration : 43mn 29s
Width : 1 920 pixels
Height : 1 072 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Language : English
Default : Yes
Forced : No
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 43mn 29s
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 44.1 KHz
Compression mode : Lossy
Language : un
Default : Yes
Forced : No
Kantana said:
It's hard to tell until devs update their apps to optimize for the Tegra K1. Software is never optimal for high bitrates. The Hi10p I am testing is 7.2Mbit/s average but in certain scenes it goes over 10Mbit/s. MXplayer and Dice player are for sure using software, if I invoke HW+ mode it speeds up but I see color blotches all over the picture similar to when playing Hi10p on unsupported hardware or codecs.
VLC beta I have it all set for hardware acceleration and the playback is perfect but the amount of heat generated and battery drain leads me to suspect it is only partially accelerated.
Once the devs optimize for the Tegra K1 we'll have a clearer picture on the capabilities of the Tegra K1.
As an aside even with h265/HEVC it was easier to play smoothly since lower bit rates:
Format : Matroska
Format version : Version 1
File size : 824 MiB
Duration : 43mn 29s
Overall bit rate : 2 649 Kbps
Writing application : DivXMKVMux 9.8.10.8454
Writing library : libDivXMediaFormat 4.0.0.0578
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Codec ID : V_MPEGH/ISO/HEVC
Duration : 43mn 29s
Width : 1 920 pixels
Height : 1 072 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Language : English
Default : Yes
Forced : No
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : A_AAC
Duration : 43mn 29s
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 44.1 KHz
Compression mode : Lossy
Language : un
Default : Yes
Forced : No
Click to expand...
Click to collapse
VLC reders clearly because by default it uses RGB 32bit video chroma while MX Player uses RGB 16bit by default. RGB 32bit need more processor power. That's why it leads to heat up issue. You can use RGB 32bit in MX Player too by changing the Settings 》 Decoder 》 Color format to RGB 32bit.
ktsamy said:
VLC reders clearly because by default it uses RGB 32bit video chroma while MX Player uses RGB 16bit by default. RGB 32bit need more processor power. That's why it leads to heat up issue. You can use RGB 32bit in MX Player too by changing the Settings 》 Decoder 》 Color format to RGB 32bit.
Click to expand...
Click to collapse
Tried that but it didn't help for Hi10p. Both HW and HW+ mode gives the blotchy/blocky renders with pink tint. I've attached a screen capture from MX player and one from VLC. SW mode doesn't have this issue on MX player but it will stutter.
H265 is played in HW on the Mipad, but still no Hi10p support in hardware. The stock video player plays h265.
Hi,
i lose some (not all) video thumbnails every 1-2 days. Is there a maximum file count/cache size for thumbnails or something that deletes old entries? I'm pretty sure i'm not having 1706 new videos every day that would roundrobin the cache.
Edit:
My cache currently holds 1706 files with 75.4M.
/storage/sdcard1/Android/data/com.mxtech.videoplayer.ad/cache/image
Code:
# ls -1 |wc -l
1706
# du -sh
75.4M .
Curious, if custom ROM, does your ROM have some sort of cache-size management?
CDB-Man said:
Curious, if custom ROM, does your ROM have some sort of cache-size management?
Click to expand...
Click to collapse
No, nothing special.
I mount some video folders occasionally to /mnt/cifs/ that get scanned by mx player as well. Maybe that confuses mx player. But if i remember correctly it also happened between two non-cifs sessions already.
The mx coder is not here? Only at Google forums?
Google Forum's been closed for a few months now, the developer's moved here along with the rest of us. See the note in my signature.
@bleu8888 is there some sort of internal MX cap on total thumbnail folder size?
My cache is still rising. Doesn't look like i'm hitting any cap here.. now 1767 files and 77.8MB.
I tested it some more and it looks like its related to the cifs share indeed (its transparent though... MX doesn't know about it. It just sees many new files). The bug seems to work "two-ways". Once cifs is mounted "local files 1" (some specific files) thumbs are missing. If i unmount cifs "local files 2" (other files) are missing. Something seems to collide here. I cannot see any relation between these files though. There are some dupe files present locally (on my phone) that are also on my desktop (cifs share) but i'm sure there are also files that are not.
I will try to setup a scenario with local files only so you can test it better. Will report back.
DualJoe said:
My cache is still rising. Doesn't look like i'm hitting any cap here.. now 1767 files and 77.8MB.
I tested it some more and it looks like its related to the cifs share indeed (its transparent though... MX doesn't know about it. It just sees many new files). The bug seems to work "two-ways". Once cifs is mounted "local files 1" (some specific files) thumbs are missing. If i unmount cifs "local files 2" (other files) are missing. Something seems to collide here. I cannot see any relation between these files though. There are some dupe files present locally (on my phone) that are also on my desktop (cifs share) but i'm sure there are also files that are not.
I will try to setup a scenario with local files only so you can test it better. Will report back.
Click to expand...
Click to collapse
I will check it out. Thanks
DualJoe said:
Hi,
i lose some (not all) video thumbnails every 1-2 days. Is there a maximum file count/cache size for thumbnails or something that deletes old entries? I'm pretty sure i'm not having 1706 new videos every day that would roundrobin the cache.
Edit:
My cache currently holds 1706 files with 75.4M.
/storage/sdcard1/Android/data/com.mxtech.videoplayer.ad/cache/image
Code:
# ls -1 |wc -l
1706
# du -sh
75.4M .
Click to expand...
Click to collapse
I believe this issue is fixed on latest test version
https://sites.google.com/site/mxvpen/translation/test-build
Feedback will be appreciated.
Thanks
bleu8888 said:
I believe this issue is fixed on latest test version
https://sites.google.com/site/mxvpen/translation/test-build
Feedback will be appreciated.
Thanks
Click to expand...
Click to collapse
Thanks, but still same behavior. I flushed the cache so i can trace the cache file count better and i've noticed the cache fluctuates indeed (when i add/remove folders). I once have 139 files. Then, when i mount new folders there's 102 files only so MX seems to try to keep it clean (what actually is a good thing). But there are always the same files missing.
These are the folders i've set in MX player. The cifs folder is either not present, empty or filled depending if mounted or not. Not sure if MX Player gets maybe confused by that behavior.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
DualJoe said:
Thanks, but still same behavior. I flushed the cache so i can trace the cache file count better and i've noticed the cache fluctuates indeed (when i add/remove folders). I once have 139 files. Then, when i mount new folders there's 102 files only so MX seems to try to keep it clean (what actually is a good thing). But there are always the same files missing.
These are the folders i've set in MX player. The cifs folder is either not present, empty or filled depending if mounted or not. Not sure if MX Player gets maybe confused by that behavior.
Click to expand...
Click to collapse
Woud you try again using latest beta version?
https://sites.google.com/site/mxvpen/translation/test-build
There is a rule for thumbnail extraction. If thumbnail extraction failed once, MX will never try again.
If storage is mounted from CIFS, MX Player will fail to extract thumbnail frequently. So it will not try to extract thumbnail because it failed once. This issue might be fixed on this build.
To make it work correctly, clear entire MX Player data.
bleu8888 said:
Woud you try again using latest beta version?
https://sites.google.com/site/mxvpen/translation/test-build
Click to expand...
Click to collapse
Bingo! Works. Thank you very much. :victory:
@bleu8888:
I've noticed that thumbnail caching acts kinda weird especially when you use the 'Quit' button (or kill the app by system settings). Currently it only caches one video here (the one on the bottom on the attached video). The behavior is dynamic though. Sometimes it caches, sometimes it does not. You probably won't notice it if you leave the player by 'back' or 'home' button. This seems completely independent from existent network/cifs folders. Can you confirm this behavior?
DualJoe said:
@bleu8888:
I've noticed that thumbnail caching acts kinda weird especially when you use the 'Quit' button (or kill the app by system settings). Currently it only caches one video here (the one on the bottom on the attached video). The behavior is dynamic though. Sometimes it caches, sometimes it does not. You probably won't notice it if you leave the player by 'back' or 'home' button. This seems completely independent from existent network/cifs folders. Can you confirm this behavior?
Click to expand...
Click to collapse
MX Player keep track of thumbnail list on an internal database.
This database looks like being corrupted when app is closed forcibly.
Database will be changed more robust on next version.
I've wiped app settings and it's working again. I also had a folder conflict (/sdcard/Android/data and /external_sd/Android/data) that was bind mounted (mirrored) manually. Currently it's working again properly (after fixing that). But the bug always needed some time to come back. Will see... Thanks so far.
bleu8888 said:
MX Player keep track of thumbnail list on an internal database.
This database looks like being corrupted when app is closed forcibly.
Database will be changed more robust on next version.
Click to expand...
Click to collapse
Unfortunately, it didn't improve the situation. It just needs some days and thumbnails get lost again. The only fix is to clear the cache to start all over. Small databases seem to work properly. That's probably why it always works when resetting MX Player. But the larger the database gets the more thumbnails get lost. Sometimes whole folders are lost and sometimes just some single files whereas the latter case is more often and leads to "persistent dead files" (thumbnails that are not stored at all - they get recreated every time one restarts MX Player). For some reason MX Player refuses to add these files or it maybe collides somewhere.
DualJoe said:
Unfortunately, it didn't improve the situation. It just needs some days and thumbnails get lost again. The only fix is to clear the cache to start all over. Small databases seem to work properly. That's probably why it always works when resetting MX Player. But the larger the database gets the more thumbnails get lost. Sometimes whole folders are lost and sometimes just some single files whereas the latter case is more often and leads to "persistent dead files" (thumbnails that are not stored at all - they get recreated every time one restarts MX Player). For some reason MX Player refuses to add these files or it maybe collides somewhere.
Click to expand...
Click to collapse
This might be due to corruption of database or file system itself.
Log will be left on this case. Would you send log after finding thumbnail lost?
bleu8888 said:
This might be due to corruption of database or file system itself.
Log will be left on this case. Would you send log after finding thumbnail lost?
Click to expand...
Click to collapse
Sure.
Full log is attached below. It contains: MX Player start, folder opened, one thumbnail appears delayed, MX Player quit. The video folder contains 13 files, all videos. Custom codec/ffmpeg is enabled.
Here is a quickly filtered version of the log (full log below):
02-07 12:26:22.106 I/ActivityManager(735): Start proc com.mxtech.videoplayer.ad for activity com.mxtech.videoplayer.ad/.ActivityMediaList: pid=26208 uid=10083 gids={50083, 3003, 1028, 1015}
02-07 12:26:22.346 I/MX (26208): CpuFamily=[1] CpuFeatures=[2047] CpuCount=[4] os.arch=[armv7l] ABIs=[armeabi-v7a;armeabi]
02-07 12:26:22.376 E/MX (26208): 26208 | Can't find symbol graphics #12
02-07 12:26:22.386 I/MX (26208): Application=[MX Player] Version=[1.7.37] Manufacturer=[samsung] Model=[GT-I9506] Display=[cm_ks01lte-userdebug 4.4.4 KTU84Q 0098ae16e5 test-keys] Brand=[samsung] Product=[ks01ltexx] Android=[4.4.4]
02-07 12:26:22.706 V/MX.Player.List.Media/MediaListFragment(26208): 5 items are built up. (33ms)
02-07 12:26:24.066 V/MX.Player.List.Media/MediaListFragment(26208): 13 items are built up. (8ms)
02-07 12:26:24.326 I/MX (26249): Application=[MX Player] Version=[1.7.37] Manufacturer=[samsung] Model=[GT-I9506] Display=[cm_ks01lte-userdebug 4.4.4 KTU84Q 0098ae16e5 test-keys] Brand=[samsung] Product=[ks01ltexx] Android=[4.4.4]
02-07 12:26:24.516 I/MX (26249): CpuFamily=[1] CpuFeatures=[2047] CpuCount=[4] os.arch=[armv7l] ABIs=[armeabi-v7a;armeabi]
02-07 12:26:24.516 E/MX (26249): 26249 | Can't find symbol graphics #12
02-07 12:26:24.526 I/MX.Player.List.Media(26208): Connected to ComponentInfo{com.mxtech.videoplayer.ad/com.mxtech.media.service.FFService}
02-07 12:26:24.766 I/MX.Player.Loader.Heavy(26208): Extracting ffmpeg thumb from /storage/sdcard1/videos/Videos3/Koreus.mp4
02-07 12:26:24.766 I/MX (26249): 26260 | Container format='mov,mp4,m4a,3gp,3g2,mj2'
02-07 12:26:24.766 W/MX.FFmpeg(26249): full chroma interpolation for destination format 'rgb565le' not yet implemented
02-07 12:26:28.956 I/ActivityManager(735): Killing 26249:com.mxtech.videoplayer.ad:remote/u0a83 (adj 11): kill background
02-07 12:26:28.956 I/ActivityManager(735): Killing 26208:com.mxtech.videoplayer.ad/u0a83 (adj 9): kill background
Click to expand...
Click to collapse
This is the mediainfo of the video (in case it matters):
Code:
General
Complete name : Koreus.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 1.34 MiB
Duration : 49s 250ms
Overall bit rate mode : Variable
Overall bit rate : 228 Kbps
Writing application : Lavf54.63.104
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : No
Format settings, ReFrames : 5 frames
Format settings, GOP : M=1, N=90
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 49s 232ms
Bit rate : 175 Kbps
Width : 400 pixels
Height : 224 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.065
Stream size : 1.03 MiB (77%)
Writing library : x264 core 142
Encoding settings : cabac=0 / ref=5 / deblock=1:0:0 / analyse=0x1:0x131 / me=umh / subme=10 / psy=0 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=24 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=90 / keyint_min=9 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=27.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=450 / vbv_bufsize=900 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=2:1.00
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AACv2 / HE-AAC / LC
Codec ID : 40
Duration : 49s 250ms
Bit rate mode : Variable
Bit rate : 48.0 Kbps
Maximum bit rate : 128 Kbps
Channel(s) : 2 channels / 1 channel / 1 channel
Channel positions : Front: L R / Front: C / Front: C
Sampling rate : 44.1 KHz / 44.1 KHz / 22.05 KHz
Compression mode : Lossy
Stream size : 289 KiB (21%)
Language : unk
Edit:
And this is a log of another folder that gets completely rescanned every time i restart MX Player:
I/Timeline( 1111): Timeline: Activity_launch_request id:com.mxtech.videoplayer.ad time:4385133
I/ActivityManager( 734): Start proc com.mxtech.videoplayer.ad for activity com.mxtech.videoplayer.ad/.ActivityMediaList: pid=4666 uid=10083 gids={50083, 3003, 1028, 1015}
I/MX ( 4666): CpuFamily=[1] CpuFeatures=[2047] CpuCount=[4] os.arch=[armv7l] ABIs=[armeabi-v7a;armeabi]
E/MX ( 4666): 4666 | Can't find symbol graphics #12
I/MX ( 4666): Application=[MX Player] Version=[1.7.37] Manufacturer=[samsung] Model=[GT-I9506] Display=[cm_ks01lte-userdebug 4.4.4 KTU84Q 0098ae16e5 test-keys] Brand=[samsung] Product=[ks01ltexx] Android=[4.4.4]
V/MX.Player.List.Media( 4666): onCreate([email protected]) saved:null intent:Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.mxtech.videoplayer.ad/.ActivityMediaList bnds=[280,1305][520,1605] }
V/MX.Player.List.Media/MediaListFragment( 4666): 5 items are built up. (27ms)
I/ActivityManager( 734): Displayed com.mxtech.videoplayer.ad/.ActivityMediaList: +747ms
I/Timeline( 734): Timeline: Activity_windows_visible id: ActivityRecord{4311d158 u0 com.mxtech.videoplayer.ad/.ActivityMediaList t22} time:4385917
V/MX.Player.List.Media/MediaListFragment( 4666): 9 items are built up. (8ms)
I/ActivityManager( 734): Start proc com.mxtech.videoplayer.ad:remote for service com.mxtech.videoplayer.ad/com.mxtech.media.service.FFService: pid=4707 uid=10083 gids={50083, 3003, 1028, 1015}
D/ActivityThread( 4707): handleBindApplication:com.mxtech.videoplayer.ad:remote
I/MX ( 4707): Application=[MX Player] Version=[1.7.37] Manufacturer=[samsung] Model=[GT-I9506] Display=[cm_ks01lte-userdebug 4.4.4 KTU84Q 0098ae16e5 test-keys] Brand=[samsung] Product=[ks01ltexx] Android=[4.4.4]
I/MX ( 4707): CpuFamily=[1] CpuFeatures=[2047] CpuCount=[4] os.arch=[armv7l] ABIs=[armeabi-v7a;armeabi]
E/MX ( 4707): 4707 | Can't find symbol graphics #12
I/MX.Player.List.Media( 4666): Connected to ComponentInfo{com.mxtech.videoplayer.ad/com.mxtech.media.service.FFService}
I/MX.Player.Loader.Heavy( 4666): Extracting ffmpeg thumb from /storage/sdcard1/videos/Videos2/Enter Pyongyang.mp4
I/MX ( 4707): 4719 | Container format='mov,mp4,m4a,3gp,3g2,mj2'
I/MX.Player.Loader.Heavy( 4666): Extracting ffmpeg thumb from /storage/sdcard1/videos/Videos2/Harzinger.mp4
I/MX ( 4707): 4718 | Container format='mov,mp4,m4a,3gp,3g2,mj2'
I/MX.Player.Loader.Heavy( 4666): Extracting ffmpeg thumb from /storage/sdcard1/videos/Videos2/One Pants No Hands.mp4
I/MX ( 4707): 4719 | Container format='mov,mp4,m4a,3gp,3g2,mj2'
I/MX.Player.Loader.Heavy( 4666): Extracting ffmpeg thumb from /storage/sdcard1/videos/Videos2/Pomsta 8 - PARANORMAL PRANK.mp4
I/MX ( 4707): 4719 | Container format='mov,mp4,m4a,3gp,3g2,mj2'
I/MX.Player.Loader.Heavy( 4666): Extracting ffmpeg thumb from /storage/sdcard1/videos/Videos2/Right Guard Sort review - FUNNY.mp4
I/MX ( 4707): 4719 | Container format='mov,mp4,m4a,3gp,3g2,mj2'
I/MX.Player.Loader.Heavy( 4666): Extracting ffmpeg thumb from /storage/sdcard1/videos/Videos2/Sex In The Bathroom Prank.mp4
I/MX ( 4707): 4722 | Container format='mov,mp4,m4a,3gp,3g2,mj2'
I/MX.Player.Loader.Heavy( 4666): Extracting ffmpeg thumb from /storage/sdcard1/videos/Videos2/Sudden Hail Storm Surprise In Novosibirsk, Russia.mp4
I/MX ( 4707): 4719 | Container format='mov,mp4,m4a,3gp,3g2,mj2'
I/MX.Player.List.Media( 4666): Connected to ComponentInfo{com.mxtech.videoplayer.ad/com.mxtech.media.service.FFService}
I/MX.Player.Loader.Heavy( 4666): Extracting ffmpeg thumb from /storage/sdcard1/videos/Videos2/Top GONE WRONG Pranks In The Hood 2014.mp4
I/MX ( 4707): 4722 | Container format='mov,mp4,m4a,3gp,3g2,mj2'
I/MX.Player.Loader.Heavy( 4666): Extracting ffmpeg thumb from /storage/sdcard1/videos/Videos2/Truck Loading.mp4
I/MX ( 4707): 4719 | Container format='mov,mp4,m4a,3gp,3g2,mj2'
I/ActivityManager( 734): Killing 4707:com.mxtech.videoplayer.ad:remote/u0a83 (adj 9): kill background
I/ActivityManager( 734): Killing 4666:com.mxtech.videoplayer.ad/u0a83 (adj 9): kill background
Click to expand...
Click to collapse
DualJoe said:
Sure.
Full log is attached below. It contains: MX Player start, folder opened, one thumbnail appears delayed, MX Player quit. The video folder contains 13 files, all videos. Custom codec/ffmpeg is enabled.
Here is a quickly filtered version of the log (full log below):
This is the mediainfo of the video (in case it matters):
Code:
General
Complete name : Koreus.mp4
Format : MPEG-4
Format profile : Base Media
Codec ID : isom
File size : 1.34 MiB
Duration : 49s 250ms
Overall bit rate mode : Variable
Overall bit rate : 228 Kbps
Writing application : Lavf54.63.104
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : [email protected]
Format settings, CABAC : No
Format settings, ReFrames : 5 frames
Format settings, GOP : M=1, N=90
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 49s 232ms
Bit rate : 175 Kbps
Width : 400 pixels
Height : 224 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 29.970 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.065
Stream size : 1.03 MiB (77%)
Writing library : x264 core 142
Encoding settings : cabac=0 / ref=5 / deblock=1:0:0 / analyse=0x1:0x131 / me=umh / subme=10 / psy=0 / mixed_ref=1 / me_range=24 / chroma_me=1 / trellis=2 / 8x8dct=0 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=0 / threads=24 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=0 / keyint=90 / keyint_min=9 / scenecut=40 / intra_refresh=0 / rc_lookahead=60 / rc=crf / mbtree=1 / crf=27.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=450 / vbv_bufsize=900 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=2:1.00
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : HE-AACv2 / HE-AAC / LC
Codec ID : 40
Duration : 49s 250ms
Bit rate mode : Variable
Bit rate : 48.0 Kbps
Maximum bit rate : 128 Kbps
Channel(s) : 2 channels / 1 channel / 1 channel
Channel positions : Front: L R / Front: C / Front: C
Sampling rate : 44.1 KHz / 44.1 KHz / 22.05 KHz
Compression mode : Lossy
Stream size : 289 KiB (21%)
Language : unk
Edit:
And this is a log of another folder that gets completely rescanned every time i restart MX Player:
Click to expand...
Click to collapse
@DualJoe I've made some improvement on writing thumbnail cache.
Kindly try latest test build: https://sites.google.com/site/mxvpen/translation/test-build
If problme continues, please send log again.
Thanks
There seems to be some kind of auto-pruning of the thumbnail cache. If folders are not present (eg. when USB or network drive are not connected) they get deleted after some time. I'm not sure when exactly. Maybe after some sessions or chronologically after a specific time. They do survive for some days though. But they are clearly gone if the folders don't come back in time.
Can you add an option to disable this behavior so the thumbnail cache can only increase? There could be a companion option 'prune now' so one could prepare the environment (mount all folders) before pruning.
I am using mx player 1.8.17 and getting green screen.Other mx player beta 1.1.02 is able to play file but dts codec is not supported nor there is option add custom codec for mx player beta 1.1.02 .Please fix it
eneral
Unique ID : 213948756896320254439955815930447190504 (0xA0F508209408FDFFBF37853F7C32D9E8)
Complete name Ok Jaanu (2017) Hindi 1080p BluRay x265 HEVC DTS 5.1 E-Sub - Team Rainbow\Sample.mkv
Format : Matroska
Format version : Version 4 / Version 2
File size : 22.8 MiB
Duration : 1 min 2 s
Overall bit rate : 3 057 kb/s
Movie name : Encoded By HiBaNA
Encoded date : UTC 2017-03-27 10:12:06
Writing application : mkvmerge v9.8.0 ('Kuglblids') 64bit
Writing library : libebml v1.3.4 + libmatroska v1.4.5
Video
ID : 1
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main [email protected]@Main
Codec ID : V_MPEGH/ISO/HEVC
Duration : 1 min 2 s
Bit rate : 2 286 kb/s
Width : 1 920 pixels
Height : 800 pixels
Display aspect ratio : 2.40:1
Frame rate mode : Constant
Frame rate : 24.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 10 bits
Bits/(Pixel*Frame) : 0.062
Stream size : 17.0 MiB (75%)
Title : Encoded By HiBaNA
Writing library : x265 2.3+22-db5e22b856f5:[Windows][GCC 6.3.0][64 bit] 10bit
Encoding settings : cpuid=1173503 / frame-threads=1 / numa-pools=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=1 / input-res=1920x800 / interlace=0 / total-frames=195888 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=4 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=24 / keyint=250 / bframes=0 / b-adapt=0 / no-b-pyramid / bframe-bias=0 / rc-lookahead=0 / lookahead-slices=4 / scenecut=0 / no-intra-refresh / ctu=64 / min-cu-size=8 / rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=2 / dynamic-rd=0.00 / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=3 / limit-modes / me=3 / subme=3 / merange=57 / temporal-mvp / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=4 / no-early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / no-b-intra / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=1.00 / no-rd-refine / analysis-mode=0 / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=abr / bitrate=2911 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / aq-mode=1 / aq-strength=1.00 / no-cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / sar=0 / overscan=0 / videoformat=5 / range=0 / colorprim=2 / transfer=2 / colormatrix=2 / chromaloc=0 / display-window=0 / max-cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / opt-qp-pps / opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / no-opt-cu-delta-qp / no-aq-motion / no-hdr / no-hdr-opt / refine-level=5
Default : Yes
Forced : No
Audio
ID : 2
Format : DTS
Format/Info : Digital Theater Systems
Mode : 16
Format settings, Endianness : Big
Codec ID : A_DTS
Duration : 1 min 2 s
Bit rate mode : Constant
Bit rate : 768 kb/s
Channel(s) : 6 channels
Channel positions : Front: L C R, Side: L R, LFE
Sampling rate : 48.0 kHz
Frame rate : 93.750 FPS (512 spf)
Bit depth : 24 bits
Compression mode : Lossy
Delay relative to video : 8 ms
Stream size : 5.72 MiB (25%)
Title : Encoded By HiBaNA
Language : Hindi
Default : Yes
Forced : No
Text
ID : 3
Format : UTF-8
Codec ID : S_TEXT/UTF8
Codec ID/Info : UTF-8 Plain Text
Duration : 39 s 334 ms
Bit rate : 45 b/s
Count of elements : 11
Stream size : 225 Bytes (0%)
Title : English SRT
Language : English
Default : Yes
Forced : No
dhruvdave said:
I am using mx player 1.8.17 and getting green screen.Other mx player beta 1.1.02 is able to play file but dts codec is not supported nor there is option add custom codec for mx player beta 1.1.02 .Please fix it
Click to expand...
Click to collapse
it will be fixed on our mainline versions on the next major update.
Beta versions doesn't support custom codec yet.
you can use the folowing temporary workaround on the main versions to avoid such green screen.
goto Settings » Decoder & change the color space to RGB16 or RGB32
Thirumalai.K said:
it will be fixed on our mainline versions on the next major update.
Beta versions doesn't support custom codec yet.
you can use the folowing temporary workaround on the main versions to avoid such green screen.
goto Settings » Decoder & change the color space to RGB16 or RGB32
Click to expand...
Click to collapse
Thank you