Hirdetés
- Samsung Galaxy A54 - türelemjáték
- HMD Skyline - jó szerelés
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- A Xiaomi 14T-k már töltő nélkül érkezhetnek
- Xiaomi 13 - felnőni nehéz
- Yettel topik
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- iPhone topik
- Samsung Galaxy A33 5G - a három az majdnem öt
- Mobil flották
Hirdetés
-
A Xiaomi 14T-k már töltő nélkül érkezhetnek
ma Legalábbis erre utal egy, a vékony dobozról készült fénykép.
-
Hosszabb videón az ingyenes játéknak készülő Ballad of Antara
gp A free-to-play akció-RPG PC-re és PlayStation 5-re érkezik, de pontos dátumot még nem kaptunk hozzá.
-
Amazon Fire TV Stick 4K Max 2nd
lo Végre megérkezett, 24 hónap garanciával!Mindenben erősebb, mint a korábbi favorit a Google Chromecast + Google TV 4K....
-
Mobilarena
Utoljára frissítve: 2024.03.06.
Légy szíves olvasd el mielőtt kérdezel!
Az összefoglalóban sok helyen a fórumtársak hozzászólásai vannak belinkelve, vagy az ő információik alapján írtam meg, tisztáztam le az adott információt. Ezúton is köszönöm mindenkinek a segítséget!
Új hozzászólás Aktív témák
-
Csicsóka
őstag
válasz varga_r #65765 üzenetére
S905x3-hoz nincs dtb az armbian-ban. x2-höz pár tipushoz van. X96Max-al szépen megy, de se wifi, se BT, gigabit ok. CE nightly dtb-vel (az van x3hoz is) el sem indul. Kerülő megoldásként, indítható a CE kernellel, úgy hogy a moduljait is át kell másolni az armbian rootfs-re. Akkor minden olyan wifi, és BT is működhet ami CE alatt megy.
-
Csicsóka
őstag
Fejlődés Armbian téren!
Az új, minden platformon működő Oleg féle Armbian, az integrált Panfrost drivernek köszönhetően egészen jól futtatja az eddig akadozó, 100% proci terheléssel járó FHD YT videókat Firefox böngészőben. Nincs akadás, a terhelés fele az eddiginek. (X96Max)
Minden más is gördülékenyebb X alatt. Már már elviselhető, egy Ryzen után. -
Csicsóka
őstag
válasz DJGABI #65865 üzenetére
Igen, arról beszélek [link].
Ha nem kell X, akkor nem hiszem hogy hozott újat. Van benne dtb S905-912 vashoz is, és X3-hoz is. Z6+-on (912) próbáltam, de az X ott addig ment, hogy elindult az asztal, de rá is fagyott az egér egyből, és onnantól csak táp kitépés lehetett, teljes fagyás. -
Csicsóka
őstag
válasz DoItYourself #65945 üzenetére
Régen nem használtam már a **MC-t, de próbáld meg, valszeg működni fog a pip-es megoldás.
-
Csicsóka
őstag
válasz junkpod #65964 üzenetére
Dehogy nem megy. Az összes régi vason 3-as kernel fut, azok nem kapták meg a 4-est.
Azért nem látsz kódokat, mert a dtb alapból meson-ir módban van, és így nem is fogja érzékelni a kernel az IR kódokat. Át kell váltani egy kamu üres remote.conf-al amremote módba, és lesznek kódok.Megoldás:
touch .config/remote.conf
rebootEgyszer újra fog indulni még, ekkor váltja a dtb-t át, de utána már:
CoreELEC (official): 9.2.0 (Amlogic.arm)
CoreELEC:~ # journalctl -f
-- Logs begin at Sat 2020-01-25 14:39:38 UTC. --
Jan 25 14:40:00 CoreELEC bluetoothd[3054]: Starting SDP server
Jan 25 14:40:00 CoreELEC kernel: Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Jan 25 14:40:00 CoreELEC kernel: Bluetooth: BNEP filters: protocol multicast
Jan 25 14:40:00 CoreELEC kernel: Bluetooth: BNEP socket layer initialized
Jan 25 14:40:00 CoreELEC bluetoothd[3054]: Bluetooth management interface 1.4 initialized
Jan 25 14:40:00 CoreELEC bluetoothd[3054]: Failed to read advertising features: Unknown Command (0x01)
Jan 25 14:40:00 CoreELEC bluetoothd[3054]: Endpoint registered: sender=:1.0 path=/MediaEndpoint/A2DPSource
Jan 25 14:40:00 CoreELEC bluetoothd[3054]: Endpoint registered: sender=:1.0 path=/MediaEndpoint/A2DPSink
Jan 25 14:40:00 CoreELEC bluetoothd[3054]: hci0 Load Connection Parameters failed: Unknown Command (0x01)
Jan 25 14:40:01 CoreELEC sshd[3039]: Accepted password for root from 10.1.1.10 port 38610 ssh2
Jan 25 14:40:10 CoreELEC kernel: remote: Wrong custom code is 0xe916fe01
Jan 25 14:40:11 CoreELEC kernel: remote: Wrong custom code is 0xe916fe01
Jan 25 14:40:13 CoreELEC kernel: remote: Wrong custom code is 0xe51afe01
Jan 25 14:40:15 CoreELEC kernel: remote: Wrong custom code is 0xaf50fe01
Jan 25 14:40:16 CoreELEC kernel: remote: Wrong custom code is 0xae51fe01
Jan 25 14:40:26 CoreELEC kernel: remote: Wrong custom code is 0xec13fe01
Jan 25 14:40:29 CoreELEC kernel: remote: Wrong custom code is 0xb847fe01
Jan 25 14:40:29 CoreELEC kernel: remote: Wrong custom code is 0xfe01fe01Ott figyelnek a kódok ahogy nyomkodtam az X96Max távját.
Ha megcsináltad a rendes configot, csak bemásolod az üres remote.conf-ba a .config könyvtárba.[ Szerkesztve ]
-
Csicsóka
őstag
válasz stigma #66059 üzenetére
Ez engem is érdekel, ha jutsz vele valamire.
Béni! #65988
Jut eszembe, ha nem elég jó a NAS, biztos van megunt box amit nem használsz.
Tehetsz rá Armbiant, arra natívan felmegy az Emby.
Vagy valamelyik boxot, amin CE van, és nézed is a mozikat, tehetsz docker-t és abba Emby servert. [link] Itt egy video. Nem olyan bonyolult mint ahogy kinéz, és így az egész hálózatodat kiszolgálja majd az az egy box. -
Csicsóka
őstag
válasz SunMount3r #66087 üzenetére
" Egy 7 portos USB 3.0-ás aktív HUB-ot kötnék rá és kitudja majd hány több TB-os winyót. Ez utóbbi megoldás okozhat bármi gondot? "
Az USB3 to SATA konverzió egy kényszer megoldás csak. Komoly NAS nem használ ilyet. Pláne nem ha RAID tömb van. Elvetemültek, a Pine64 fórumon görcsöltek vele, de mindenkinek széthullott, instabil fo* volt, és siralmas sebességet tudott csak, USB3-on.
A mostani egyik legjobb SBC erre, amin van PCI-E a RockPro64
[link] Ebbe bele egy PCI-E to SATA kártya, és mehet akár 4 db. HDD is. Ebben [link] a videóban megmutatja mit tud. A rátett SSD-n, direct (nem bufferelt) olvasási sebesség 260MB/s körüli. ARM vastól ez nem rossz, bár egy Ryzen ettől többet tud, (450MB/s) itt már nincs CPU limit. -
Csicsóka
őstag
válasz evitiguF #66226 üzenetére
1. Semmit sem ír a boxra, ha SD-ről fut. Felesleges még1x futtatni a frissítést, mert már lefutott.
2. csinálsz egy remote.conf fájlt ezzel a tartalommal, és bemásolod az SD gyökerébe. Lesz utána távirányító. Pár gomb módosítva van benne, de azt kommenteztem.#amlogic NEC remote
work_mode = 0
repeat_enable = 1
repeat_delay = 130
repeat_peroid = 120
release_delay = 20
debug_enable = 1
factory_code = 0xfe010001key_begin
0x40 116 #ON/OFF
0x11 102 #HOME
0x19 158 #EXIT
0x4c 125 #MENU
0x18 115 #VOL+
0x10 114 #VOL-
0x16 103 #UP
0x51 105 #LEFT
0x13 97 #OK
0x50 106 #RIGHT
0x1a 108 #DOWN
0x5a 57 #PLAY_PAUSE -> Space (Pause/Play)
0x42 20 #DEL -> T (Toggle subtitles on and off)
0x47 24 #@ -> O (Codec info)
0x43 45 #SETTINGS -> X (Stop)
0x59 19 #PREV -> R (Rewind)
0x58 33 #NEXT -> F (Fast forward)
0x4e 2 #1
0x0d 3 #2
0x0c 4 #3
0x4a 5 #4
0x09 6 #5
0x08 7 #6
0x46 8 #7
0x05 9 #8
0x04 10 #9
0x01 11 #0
key_end -
Csicsóka
őstag
válasz pixta78 #66252 üzenetére
" "kiszolgáló neve" lehet IP"
Lehet, de nem célszerű, mert akkor a szervernek fix IP kell.
Ami ha az egy igazi SMB szerver nem is gond, de ha egy dózer PC az asztalon, akkor erre is figyelni kell.
Szerver névvel meg tök mind1.Részlet egy smb.conf-ból:
[global]
workgroup = WORKGROUP
server string = Bpi-M2u
netbios name = Bpi-M2u
security = user
map to guest = bad user
dns proxy = noA server string-el hirdeti magát a hálózaton, így nem kell IP.
-
Csicsóka
őstag
Eddig nem csináltam nightly-ből felezőst, mert nincs értelme.
Ránézek az auto update-ra, ha ki tudom belőle szedni akkor esetleg lehetne próbálkozni vele. A nagymenők úgy sem fogják ezt a funkciót kikapcsolni, hiába sír nekik bárki. (Pedig baromság nem kapcsolhatóvá tenni) Nincs x3 vasam, úgy hogy ez a téma nem élvez prioritást. -
Csicsóka
őstag
Nightly automatikus frissítés tiltása.
Ez egy nem propagált lehetőség, mivel a nagymenők ezt nem támogatják.
Bele néztem a a CE frissítési folyamatába, és meglett a kiskapu, ami mindig is ott volt, kihasználatlanul.A service.corelec.settings addon felel többek közt ezért is.
Az egyik Python szkriptben benne a lehetőség a frissítés tiltására.
Ahhoz hogy ez a lekérdezés működjön, az alábbi a teendő:Az autostart.sh-ba az alábbi sort kell beírni:
touch /dev/.update_disabled
Reboot után nem ellenőrzi többet, a lehetséges frissítéseket, nem is ajánlja fel.
Megszabadulni tőle a sor törlésével, vagy a sor elé tett kommenttel lehet.
így:#touch /dev/.update_disabled
Ha nincs még autostart.sh akkor:
echo "touch /dev/.update_disabled" > .config/autostart.sh
-
Csicsóka
őstag
Emby addon-t használnék, direkt média elérés módban, amikor az NFS megosztást használja a fájlok eléréséhez. Minden jó, kivéve az, hogy a félbehagyott anyagok folytatását nem ajánlja fel, a megnézetteket nem jelöli. Alap módban minden ok.
Lehet ezt valahogy orvosolni?
Úgy rémlik, mikor régen PLEX-et használtam az nem csinált ilyet.[ Szerkesztve ]
-
Csicsóka
őstag
Ha rá lettem volna kényszerítve hogy nightly-t használjak, már régen kikerestem volna valami megoldást. Nagyon utáltam akkor is amikor a felezőst csináltam, és próbáltam az oda vissza frissítést. A szemét háttérben letöltötte mindig a .tar-t, úgy kellett kézzel reboot előtt törölni. -
Csicsóka
őstag
válasz DroiDMester #66404 üzenetére
Mert ez a "buherálás" aztán qrva bonyolult mi? Nem fog utána se jelezni se kérdezni semmi. Kattintgass csak nyugodtan, ha az boldogít.
Megint nekem akarsz magyarázni, mit hogy lehet...[ Szerkesztve ]
-
Csicsóka
őstag
válasz kovakovi77 #66896 üzenetére
A duálosított rendszerünk pedig még egy frissitéssel sem vágja gajra a rendszert, hiszen régi backup kernelt vissza másolva és voiala működik.
Ellenben, a ceemmc-vel dualosra telepített cuccon a CE /storage-t, egy kattintással törölni lehet a data-ról, droid fájlkezelőben. A közösen használt data egy coreelec nevű könyvtárába települ az egész storage, amit figyelmetlenségből, vagy tudatlanságból a droid user egy pillant alatt kinyírhat, és oda az egész belakott kodi.
Az egy perces boot időt, én csak egy napig tudtam tolerálni, le is túrtam, és ment vissza a negyedelős rendszer, 9 másodperces boot idővel.
Ettől pedig a most éledező SSD-re települő NG ext4 lesz gyorsabb.
Ott a 100MB/s eMMC vs 400MB/s SSD sebesség különbség még brutálisabb időket fog majd futni. -
Csicsóka
őstag
válasz hunaqua #66903 üzenetére
Korábban voltak ezzel a belső SATA-val táp problémák.
Kovakövi kolléga említette anno hogy nem kapott az USB-n keresztül tápot. Ez már megoldódott azóta?
Mert csak így tudna onnan bootolni. Akkor viszont az újra élesztett ext4 lenne a legjobb erre, (és más NG) a vasra. Három felé lesz particionálva az SSD, boot, rootfs, és a többi terület egyéb tárolási feladatra (torrent? chroot-olt Debian?). Egy USB3 pendrive-on már most nagyon jól megy. -
Csicsóka
őstag
válasz SunMount3r #66952 üzenetére
Itt nem desktop megoldásra kell gondolni. Egyszerű minimal Debian telepítést, az SSD 3. partíciójára másolva, lehet azt futtatni chroot környezetben, (ez egy virtuális géphez hasonló dolog, leegyszerűsítve) Leginkább arra jó, hogy ami nincs meg az entware-ben, a Debianban biztos hogy van, ezért lehet onnan futtatni.
-
Csicsóka
őstag
válasz junkpod #66956 üzenetére
Van a kernel init-ben egy max 15 másodperces ciklus, ami a /flash-t és a /storage-t mountolja fel. Ha az eszköz készen áll a mountolásra akkor is eltelik 1-2 sec, de ha nem mer nincs jelen a rendszerben, akkor 2x15x2 az idő amit kivár, ez meg 60 sec.
Ez a magyarázat a hosszú boot időre akkor.Erről beszélek:
# Mount handlers
# All handlers take the following parameters:
# $1:target, $2:mountpoint, $3:mount options, [$4:fs type]
mount_common() {
# Common mount handler, handles block devices and filesystem images
MOUNT_OPTIONS="-o $3"
[ -n "$4" ] && MOUNT_OPTIONS="-t $4 $MOUNT_OPTIONS"
for i in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15; do
ERR_ENV=1
mount $MOUNT_OPTIONS $1 $2 >&$SILENT_OUT 2>&1
[ "$?" -eq "0" ] && ERR_ENV=0 && break
usleep 1000000
done
[ "$ERR_ENV" -eq "0" ] && return 0
error "mount_common" "Could not mount $1"
}
Új hozzászólás Aktív témák
Hirdetés
Állásajánlatok
Cég: Ozeki Kft
Város: Debrecen
Cég: Ozeki Kft
Város: Debrecen