I recently set up my rock64 4GB with debian 9 as a media box.

I installed plex and rtorrent and everything is going smoothly. The only problem I have is that after a few hours (probably 6/7 hours) of "work" both my HDDs (one on USB 3.0 the other on the 2.0) slow down from 70-90MB/s to 6-7MB/s. The speed drop happens with all the programs: samba, ftp, rtorrent etc.

The only way to get performance up again is to remount both drives. At that point I get 70-90MB/s back.

My fstab:

Title says it all.

All images in Pine64+ are old paricularly android images.

Are Pinebook images compatible with Pine64+?

I tried to boot Manjaro LXQT image but there was no screen activity.

If they are not compatible how to modify them?

Anyone else problem with Armbian and getting no sound from the jack?
When I open a music stream and have a look in the volume control I see the graphic VU bar moving. Tried different stuff but can't find the solution from the problem.


I'm a total Linux n00b but I did find a command on the internet which I tried and said this:

[email protected]:/etc/alsa/conf.d$ aplay -L
default
    Playback/recording through the PulseAudio sound server
null
    Discard all samples (playback) or generate zero samples (capture)
jack
    JACK Audio Connection Kit
pulse
    PulseAudio Sound Server
sysdefault:CARD=rkes8316hpsound
    rk-es8316-hp-sound,
    Default Audio Device
dmix:CARD=rkes8316hpsound,DEV=0
    rk-es8316-hp-sound,
    Direct sample mixing device
dsnoop:CARD=rkes8316hpsound,DEV=0
    rk-es8316-hp-sound,
    Direct sample snooping device
hw:CARD=rkes8316hpsound,DEV=0
    rk-es8316-hp-sound,
    Direct hardware device without any conversions
plughw:CARD=rkes8316hpsound,DEV=0
    rk-es8316-hp-sound,
    Hardware device with all software conversions
usbstream:CARD=rkes8316hpsound
    rk-es8316-hp-sound
    USB Stream Output
sysdefault:CARD=rkspdifsound
    rk-spdif-sound,
    Default Audio Device
dmix:CARD=rkspdifsound,DEV=0
    rk-spdif-sound,
    Direct sample mixing device
dsnoop:CARD=rkspdifsound,DEV=0
    rk-spdif-sound,
    Direct sample snooping device
hw:CARD=rkspdifsound,DEV=0
    rk-spdif-sound,
    Direct hardware device without any conversions
plughw:CARD=rkspdifsound,DEV=0
    rk-spdif-sound,
    Hardware device with all software conversions
usbstream:CARD=rkspdifsound
    rk-spdif-sound
    USB Stream Output
sysdefault:CARD=rkhdmidpsound
    rk-hdmi-dp-sound,
    Default Audio Device
dmix:CARD=rkhdmidpsound,DEV=0
    rk-hdmi-dp-sound,
    Direct sample mixing device
dsnoop:CARD=rkhdmidpsound,DEV=0
    rk-hdmi-dp-sound,
    Direct sample snooping device
hw:CARD=rkhdmidpsound,DEV=0
    rk-hdmi-dp-sound,
    Direct hardware device without any conversions
plughw:CARD=rkhdmidpsound,DEV=0
    rk-hdmi-dp-sound,
    Hardware device with all software conversions
usbstream:CARD=rkhdmidpsound
    rk-hdmi-dp-sound
    USB Stream Output
[email protected]:/etc/alsa/conf.d$

The initial announcement had some vague stuff about working with KDE. Is a custom KDE Neon version (like for the original Pinebook) in the works?

I started to reply to mmatyas thread but I feel like this is something different. Where mmatyas started with ayufan's Debian and performed a sloppy hack to turn it into ArchLinuxArm, I'm starting with Manjaro and attempting a sloppy hack but I'm not having any luck...yet.
Edit: I prematurely wrote that I'm not having any luck. I was successful in working back through method 2.

Method 1:
1) Follow installation steps 1 trough 6 on Arch Linux ARM's Rock64 page.
2) Download and extract Manjaro image (this exact image may be nonexistent or outdated as you're reading this)
3) Copy boot.scr, idbloader.img, trust.img, and uboot.img from the boot directory of the extracted Manjaro image.
4) Continue following steps 7 through 9 Arch Linux ARM's Rock64 page using Manjaro's boot.scr, idbloader.img, trust.img, and uboot.img instead of downloading from archlinuxarm.org.
5) Attempt to boot.
I'm hoping someone can explain to me why I'm an idiot and this doesn't work.

Method 2:
1) Burn before-mentioned Manjaro image to disk and boot into Manjaro.
2) # cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.bup
3) # echo 'Server = http://mirror.archlinuxarm.org/$arch/$repo" > /etc/pacman.d/mirrorlist
4) # rm /etc/lsb-release
5) # pacman-key init
6) # pacman-key --populate archlinuxarm
7) # pacman -Syu base-devel git
8) $ git clone https://gitlab.manjaro.org/manjaro-arm/p...kpro64.git
9) $ cd uboot-rockpro64
10) $ makepkg -si
11) Reboot and wait very patiently (several minutes).

Czy sprzęt nie mógłby przypadkiem być uzywany przez fundację jeden laptop dla jednego dziecka?

Chętnie bym kupił np. taki sprzęt dla Caritas-u ale dobrze by było by fundacja przeniosła 'shugar' czyli swoje autorskie gui. Aby dało się np. dadać jakiś sposób na doładowywanie z panelu slonecznego czy elektrowni wiatrowej (zapewne by działal też jakiś router i jak już internet z satelity będzie dostepny modem )

Projekt robi dużo dobrego i myśle, że warto połączyć siły. Kiedyś pracowali nad tabletem z panelem slonecznym
(zobaczcie rok! tej propozycji)  http://one.laptop.org/about/xo-3


Przyznam, że wizja laptopa z routerem działającego niezależnie od sieci energetycznej (a w przyszłości niezależnie od dostawców (lorawan, wifimesh) jest bardzo miła memu sercu.


Zatem warto połączyć siły i robić coś dla ludzkości.

https://www.vmall.com/list-42

Wydaje się, że wojna handlowa zmieniła reguły gry. Chińczycy, którzy bali się open source zaczynają otwierać się na otwarte rozwiązania. Moim zdaniem to zmienia całkiem reguły gry i jedt dobre dla użytkownika.

Obawiam się tylko o bezpieczeństwo. Nie wierzę by nie było tam jakiś tylnych furtek, to że działa linux nie oznacza, ze wszystko jest otwarte. Na pewno coś sobie zostawili

Huawei starting sell linux laptops. I dont know how many blobs and closed source are inside but this is trouble. Big game begining

in polish language https://www.dobreprogramy.pl/Huawei-sprz...03664.html

This is the PineTime, a side-project of ours. If you are a rtos or mbed developer and have an interest in smartwatches make sure to PM me on the forum or in the chats.

There are a few interesting mobile image enhancement techniques which could be very useful if implemented on the PINE64 mobile devices. They could very well improve the decent cameras on the devices to something quite admirable.

The main projects I'd like to see implemented are:

HDRnet - uses downsampling and neural networks to improve image truth, vibrancy, or style. Already has been shown to work on mobile with speed. An open source (Apache 2.0) implementation can be found at https://github.com/mgharbi/hdrnet/ and https://github.com/google/hdrnet/

HDR+ - better automatic RAW development, can align multiple frames and improve color range. I believe it is used on Google phones. An open source (MIT,  maybe incomplete) implementation can be found at https://github.com/timothybrooks/hdr-plus

Handheld Multi-frame Super-resolution - merges many images (like those from a live photo) into a higher resolution image. It might be used on Google phones. I don't know of any existing working open source implementation, but this (MIT, very incomplete) may implement it in the future https://github.com/JVision/Handheld-Mult...Resolution

Learning to See in the Dark - intelligent RAW developer which can brighten an image by an extremely large magnitude. I am unsure about the performance, especially on mobile. An open source (MIT) implementation can be found at https://github.com/cchen156/Learning-to-See-in-the-Dark

I mention these projects on the PINE64 forums rather than another forum (like the PostmarketOS or Ubuntu Touch forums) because these projects would likely benefit from firmware enhancements, and splitting the topics across many forums would be a pain to deal with.

I should also mention that I'm in no way a neural network or image processing expert, but I'm sure some other members of the forum are. Maybe this post will catch their interest?