Kikat - Wasser Firmware for Beelink R89

[Gilgamesh]

thank you I found it now, thought of using Class 10 16GB microSD for Titanium Backup and store other files on it instead of the internal memory, keep it clean and for installing apps only.

[nir]

Tronsmart firmware

Hi there, I need help :\


I'm trying to flash the wasser firmware to my Tronsmart r28 with AndroidTool 2.3

Frimware file name: wasser-2.0.3-beelink-r89-rk3288
From: http://www.freaktab.com/showthread.php?2...nsmart+r28
But when I'm pressing on Upgrade I'm getting the message: "Match device type failed,stop running!"

How can I fix it?

[gffmac]

Hi there, I need help :\


I'm trying to flash the wasser firmware to my Tronsmart r28 with AndroidTool 2.3

Frimware file name: wasser-2.0.3-beelink-r89-rk3288
From: http://www.freaktab.com/showthread.php?2...nsmart+r28
But when I'm pressing on Upgrade I'm getting the message: "Match device type failed,stop running!"

How can I fix it?

If you have usb debugging enabled you can hit the switch button then the upgrade button.

[ICU]

Thanks for all the info gormar. I'm ready to sell my bee link r89. IMHO it is junk. Micro glitches all the time with every combination of devices hooked up to different usb ports. my 500 gig usb hdd causes big stutters. all i wanted was to watch movies stutter free and have an air mouse and external usb hdd hooked up. unfortunately if i hook air mouse uo with external hdd system stutters bad watching videos. so i will wait till firmware 111k4 is released and if my issues arent fixed im selling my box and will buy a nuc maybe. i love android os for the apps and games and this box is good for that but if you want smooth video playback especially from external hdd then i cant recommend beelink r89. the stutter gives me a headache and image a bit blurry. definately not smooth at all. i would like to know if the nagace v~6 has these issues?

[Gormar]

@ICU. Hold your horses for a moment . I've just found something strange. There are writes to disk quite often because jbd2 process is updating EXT4 jurnal and sometime kworker is hiking along repeatedly every 5-6 seconds. These operations doesn't generate too much data because only 4kB (8 sectors) is written for each but if we have 30-40 similar events in one second and factor poor IO performance of this device eMMC then it isn't funny.

<7>[12447.539933] jbd2/mmcblk0p13(128): WRITE block 12891048 on mmcblk0p13 (8 sectors)
<7>[12447.539943] jbd2/mmcblk0p13(128): WRITE block 12891056 on mmcblk0p13 (8 sectors)<7>[12447.539950] jbd2/mmcblk0p13(128): WRITE block 12891064 on mmcblk0p13 (8 sectors)
<7>[12447.539956] jbd2/mmcblk0p13(128): WRITE block 12891072 on mmcblk0p13 (8 sectors)
<7>[12447.539962] jbd2/mmcblk0p13(128): WRITE block 12891080 on mmcblk0p13 (8 sectors)
<7>[12447.539968] jbd2/mmcblk0p13(128): WRITE block 12891088 on mmcblk0p13 (8 sectors)
<7>[12447.539974] jbd2/mmcblk0p13(128): WRITE block 12891096 on mmcblk0p13 (8 sectors)
<7>[12447.539980] jbd2/mmcblk0p13(128): WRITE block 12891104 on mmcblk0p13 (8 sectors)
<7>[12447.541830] jbd2/mmcblk0p13(128): WRITE block 12891112 on mmcblk0p13 (8 sectors)
<7>[12447.557419] Thread-98(13661): WRITE block 14509552 on mmcblk0p13 (8 sectors)
<7>[12447.558230] Thread-98(13661): WRITE block 14509560 on mmcblk0p13 (8 sectors)
<7>[12447.558245] Thread-98(13661): WRITE block 525280 on mmcblk0p13 (8 sectors)
<7>[12447.558257] Thread-98(13661): WRITE block 525296 on mmcblk0p13 (8 sectors)
<7>[12447.560543] Thread-98(13661): WRITE block 14509552 on mmcblk0p13 (8 sectors)
<7>[12447.670099] kworker/u8:1(12837): WRITE block 12583000 on mmcblk0p13 (8 sectors)
<7>[12447.670119] kworker/u8:1(12837): WRITE block 12583040 on mmcblk0p13 (8 sectors)
<7>[12447.670129] kworker/u8:1(12837): WRITE block 12583576 on mmcblk0p13 (8 sectors)
<7>[12447.670139] kworker/u8:1(12837): WRITE block 12583592 on mmcblk0p13 (8 sectors)
<7>[12447.670150] kworker/u8:1(12837): WRITE block 12583760 on mmcblk0p13 (8 sectors)
<7>[12447.670165] kworker/u8:1(12837): WRITE block 12583880 on mmcblk0p13 (8 sectors)
<7>[12447.670174] kworker/u8:1(12837): WRITE block 12649248 on mmcblk0p13 (8 sectors)
<7>[12447.670183] kworker/u8:1(12837): WRITE block 20971528 on mmcblk0p13 (8 sectors)
<7>[12447.670192] kworker/u8:1(12837): WRITE block 20971576 on mmcblk0p13 (8 sectors)
<7>[12447.670202] kworker/u8:1(12837): WRITE block 20971648 on mmcblk0p13 (8 sectors)
<7>[12447.670212] kworker/u8:1(12837): WRITE block 20971872 on mmcblk0p13 (8 sectors)
<7>[12447.670221] kworker/u8:1(12837): WRITE block 20971896 on mmcblk0p13 (8 sectors)
<7>[12447.670231] kworker/u8:1(12837): WRITE block 20972144 on mmcblk0p13 (8 sectors)
<7>[12447.670244] kworker/u8:1(12837): WRITE block 21038240 on mmcblk0p13 (8 sectors)
<7>[12447.670253] kworker/u8:1(12837): WRITE block 21038248 on mmcblk0p13 (8 sectors)
<7>[12447.670262] kworker/u8:1(12837): WRITE block 21038296 on mmcblk0p13 (8 sectors)
<7>[12447.670280] kworker/u8:1(12837): WRITE block 0 on mmcblk0p13 (8 sectors)
<7>[12447.670289] kworker/u8:1(12837): WRITE block 8 on mmcblk0p13 (8 sectors)
<7>[12447.670297] kworker/u8:1(12837): WRITE block 8388736 on mmcblk0p13 (8 sectors)
<7>[12447.670325] kworker/u8:1(12837): WRITE block 8388752 on mmcblk0p13 (8 sectors)
<7>[12447.670336] kworker/u8:1(12837): WRITE block 8388960 on mmcblk0p13 (8 sectors)
<7>[12447.670346] kworker/u8:1(12837): WRITE block 8389600 on mmcblk0p13 (8 sectors)
<7>[12447.670356] kworker/u8:1(12837): WRITE block 8391976 on mmcblk0p13 (8 sectors)
<7>[12447.670365] kworker/u8:1(12837): WRITE block 8399648 on mmcblk0p13 (8 sectors)
<7>[12447.670374] kworker/u8:1(12837): WRITE block 8399656 on mmcblk0p13 (8 sectors)
<7>[12447.670382] kworker/u8:1(12837): WRITE block 8455024 on mmcblk0p13 (8 sectors)
<7>[12447.670391] kworker/u8:1(12837): WRITE block 8456672 on mmcblk0p13 (8 sectors)
<7>[12447.670402] kworker/u8:1(12837): WRITE block 12582936 on mmcblk0p13 (8 sectors)
<7>[12448.654973] kworker/u8:3(13334): WRITE block 22871632 on mmcblk0p13 (72 sectors)

To log these operation in debug messages (dmesg) you should enable debug in VM for block_dumps, like that:
echo "1" > /proc/sys/vm/block_dump
Disable:
echo "0" > /proc/sys/vm/block_dump

Tomorow I will check if my old BOX have similar behavior. Maybe this device is salvageable

[Gilgamesh]

@Gormar

is that good news or what?

[Gormar]

@Gilgamesh. Right now I realy don't know. But I would rather don't have so many write operation on eMMC just from durability stand point.

P.S. "commit=60" as mount option doesn't seem to resolve this issue.

[Hui91]

still having this issue! Any one else?

Hi Wasser,

I still have this coloring issue presented with your ROM. ( Tried another HDMI cable, still same.
Any idea what would this be? It stays like this for a minute or so, then back to normal, and a few minutes later again.

[georget]

If you unplug the HDMI cable in back of the box for a second, then plug it back in, do you see the correct colors? I have seen this before when using a HDMI > DVI cable with other boxes and firmware. I have not seen it with Wasser's BeeLink firmware.

[nir]

DD & DTS

Hi

I updated my Tronsmart R28 to Wasser firmware,
The spdif connected to Yamaha reciver,unfortunately I cann't get 5.1CH, When I'm using XBMC latest version, I'm getting PCM 2CH on my reciver(while xbmc playing AAC 5.1 movie).
I tryied to use spdif passthrough but it still PCM 2ch on the reciver.


Is that normal?

[mo123]

Hi

I updated my Tronsmart R28 to Wasser firmware,
The spdif connected to Yamaha reciver,unfortunately I cann't get 5.1CH, When I'm using XBMC latest version, I'm getting PCM 2CH on my reciver(while xbmc playing AAC 5.1 movie).
I tryied to use spdif passthrough but it still PCM 2ch on the reciver.


Is that normal?

Are you using SPMC and set audio to HDMI Bitstream?

[nir]

Are you using SPMC and set audio to HDMI Bitstream?

Nope I'm using Kodi 14 Helix, using Spdif cable for the reciver and HDMI output for tv.

[Hui91]

If you unplug the HDMI cable in back of the box for a second, then plug it back in, do you see the correct colors? I have seen this before when using a HDMI > DVI cable with other boxes and firmware. I have not seen it with Wasser's BeeLink firmware.

Yes it goes back to normal for a while, then happens again. I tried with 2 HDMI-HDMI cables.

[ICU]

Would be nice if something could be done about the stutter of beelink r89. Im at the point of no return with it. I got a samsung f-355 sound bar and when i connect via sony/phillips digital interface all videos stutter bad and watching 1080p mkv or mp4 off external usb hdd while using air mouse listening with spdif sound is a total joke. lol will drive a person nuts within 1 minute. I should have bought a nuc because my main priority is watching movies and xbmc but i thought getting a rk3288 box and being able to watch movie/ stream on an android os with its games and apps would be a dream. i guess it was a dream because i must have been asleep to have believe it. this box is great if you dont watch movies. asphalt 8 and most apps work great but its not the main reason i bought this box. so after next firmware update from rockchip if i dont have these issues addressed my box will be sold for cheap.

@ICU. Hold your horses for a moment . I've just found something strange. There are writes to disk quite often because jbd2 process is updating EXT4 jurnal and sometime kworker is hiking along repeatedly every 5-6 seconds. These operations doesn't generate too much data because only 4kB (8 sectors) is written for each but if we have 30-40 similar events in one second and factor poor IO performance of this device eMMC then it isn't funny.

<7>[12447.539933] jbd2/mmcblk0p13(128): WRITE block 12891048 on mmcblk0p13 (8 sectors)
<7>[12447.539943] jbd2/mmcblk0p13(128): WRITE block 12891056 on mmcblk0p13 (8 sectors)<7>[12447.539950] jbd2/mmcblk0p13(128): WRITE block 12891064 on mmcblk0p13 (8 sectors)
<7>[12447.539956] jbd2/mmcblk0p13(128): WRITE block 12891072 on mmcblk0p13 (8 sectors)
<7>[12447.539962] jbd2/mmcblk0p13(128): WRITE block 12891080 on mmcblk0p13 (8 sectors)
<7>[12447.539968] jbd2/mmcblk0p13(128): WRITE block 12891088 on mmcblk0p13 (8 sectors)
<7>[12447.539974] jbd2/mmcblk0p13(128): WRITE block 12891096 on mmcblk0p13 (8 sectors)
<7>[12447.539980] jbd2/mmcblk0p13(128): WRITE block 12891104 on mmcblk0p13 (8 sectors)
<7>[12447.541830] jbd2/mmcblk0p13(128): WRITE block 12891112 on mmcblk0p13 (8 sectors)
<7>[12447.557419] Thread-98(13661): WRITE block 14509552 on mmcblk0p13 (8 sectors)
<7>[12447.558230] Thread-98(13661): WRITE block 14509560 on mmcblk0p13 (8 sectors)
<7>[12447.558245] Thread-98(13661): WRITE block 525280 on mmcblk0p13 (8 sectors)
<7>[12447.558257] Thread-98(13661): WRITE block 525296 on mmcblk0p13 (8 sectors)
<7>[12447.560543] Thread-98(13661): WRITE block 14509552 on mmcblk0p13 (8 sectors)
<7>[12447.670099] kworker/u8:1(12837): WRITE block 12583000 on mmcblk0p13 (8 sectors)
<7>[12447.670119] kworker/u8:1(12837): WRITE block 12583040 on mmcblk0p13 (8 sectors)
<7>[12447.670129] kworker/u8:1(12837): WRITE block 12583576 on mmcblk0p13 (8 sectors)
<7>[12447.670139] kworker/u8:1(12837): WRITE block 12583592 on mmcblk0p13 (8 sectors)
<7>[12447.670150] kworker/u8:1(12837): WRITE block 12583760 on mmcblk0p13 (8 sectors)
<7>[12447.670165] kworker/u8:1(12837): WRITE block 12583880 on mmcblk0p13 (8 sectors)
<7>[12447.670174] kworker/u8:1(12837): WRITE block 12649248 on mmcblk0p13 (8 sectors)
<7>[12447.670183] kworker/u8:1(12837): WRITE block 20971528 on mmcblk0p13 (8 sectors)
<7>[12447.670192] kworker/u8:1(12837): WRITE block 20971576 on mmcblk0p13 (8 sectors)
<7>[12447.670202] kworker/u8:1(12837): WRITE block 20971648 on mmcblk0p13 (8 sectors)
<7>[12447.670212] kworker/u8:1(12837): WRITE block 20971872 on mmcblk0p13 (8 sectors)
<7>[12447.670221] kworker/u8:1(12837): WRITE block 20971896 on mmcblk0p13 (8 sectors)
<7>[12447.670231] kworker/u8:1(12837): WRITE block 20972144 on mmcblk0p13 (8 sectors)
<7>[12447.670244] kworker/u8:1(12837): WRITE block 21038240 on mmcblk0p13 (8 sectors)
<7>[12447.670253] kworker/u8:1(12837): WRITE block 21038248 on mmcblk0p13 (8 sectors)
<7>[12447.670262] kworker/u8:1(12837): WRITE block 21038296 on mmcblk0p13 (8 sectors)
<7>[12447.670280] kworker/u8:1(12837): WRITE block 0 on mmcblk0p13 (8 sectors)
<7>[12447.670289] kworker/u8:1(12837): WRITE block 8 on mmcblk0p13 (8 sectors)
<7>[12447.670297] kworker/u8:1(12837): WRITE block 8388736 on mmcblk0p13 (8 sectors)
<7>[12447.670325] kworker/u8:1(12837): WRITE block 8388752 on mmcblk0p13 (8 sectors)
<7>[12447.670336] kworker/u8:1(12837): WRITE block 8388960 on mmcblk0p13 (8 sectors)
<7>[12447.670346] kworker/u8:1(12837): WRITE block 8389600 on mmcblk0p13 (8 sectors)
<7>[12447.670356] kworker/u8:1(12837): WRITE block 8391976 on mmcblk0p13 (8 sectors)
<7>[12447.670365] kworker/u8:1(12837): WRITE block 8399648 on mmcblk0p13 (8 sectors)
<7>[12447.670374] kworker/u8:1(12837): WRITE block 8399656 on mmcblk0p13 (8 sectors)
<7>[12447.670382] kworker/u8:1(12837): WRITE block 8455024 on mmcblk0p13 (8 sectors)
<7>[12447.670391] kworker/u8:1(12837): WRITE block 8456672 on mmcblk0p13 (8 sectors)
<7>[12447.670402] kworker/u8:1(12837): WRITE block 12582936 on mmcblk0p13 (8 sectors)
<7>[12448.654973] kworker/u8:3(13334): WRITE block 22871632 on mmcblk0p13 (72 sectors)

To log these operation in debug messages (dmesg) you should enable debug in VM for block_dumps, like that:
echo "1" > /proc/sys/vm/block_dump
Disable:
echo "0" > /proc/sys/vm/block_dump

Tomorow I will check if my old BOX have similar behavior. Maybe this device is salvageable

[Gilgamesh]

well I tried with Plex Media Server today from my PC and streamed to the R28 Meta which I have the Plex app for Android installed, I tried with some videos for example a 12GB 1080p DTS Blu-ray rip of The Dark Knight Rises, it played it without any problem, so for the moment I'm happy but I always hope for improved firmwares... btw I don't do games, I bought it only for watching movies...I have my PC for games.

Tapatalked from my GALAXY S5