ffmpeg|avconv -i input.m4v -vcodec copy -acodec copy out.mkv
So easy this post is actually done here.
… use eyed3 for your command line tagging/display needs instead. Seriously, if you write id3v2.4 tags (which I guess most taggers do nowadays), id3v2 unfortunately doesn’t see/support them.
Ever wondered what specifications your harddisk/SSD actually has? hdparm is your best friend here. I wondered whether my Corsair SSD actually had TRIM supported/enabled, and this is what
sudo hdparm -I /dev/sda (of course, replace
/dev/sda with w/e your desired device node is) got me:
You get this?
perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = “en_US.UTF-8″, LC_ALL = “en_US.UTF-8″, LANG = “en_US.UTF-8″ are supported and installed on your system.
export LANGUAGE=en_US.UTF-8 export LANG=en_US.UTF-8 export LC_ALL=en_US.UTF-8 locale-gen en_US.UTF-8 dpkg-reconfigure locales
Worked for me. Of course, replace
en_US with w/e your primary language is.
Sometimes I get some crappy zipped/rared/whatever packages that contain filenames that are not UTF-8 encoded, mostly from old package programs used on the Windows platform. What happens is that those packages will unpack just fine, but more often than not you end up with filenames that contain non-printable characters. PITA if there’s a lot of them. tr to the rescue!
ls -1 | while read file; do N=$(echo $file | tr -cd '\11\12\40-\176'); mv "$file" "$N"; done
What this does is basically:
- get every filename in the current directory and toss it to tr
- the -c and -d options used like this command tr to only output characters that we actually specify
- the quoted argument tells tr to only retain the octal characters 11, 12 and 40 to 176. Octal 11 is Tab, 12 is linefeed (technically, this should be omitted from a filename, but I also use this to filter textfiles, so it comes in handy and is of no real harm here). 40 to 176 are the standard keyboard characters from space to ~, which we actually like in our filenames.
- finally, we move the garbled filename to the new, cleaned up version.
As good as Nomachine’s NX is … the documentation is seriously confusing and all over the place with some documents more complete than others.
I tried to check out their new 4.x preview just yet (oh, and no, it’s definitely not ready for production), and as I always do, generate my own keys to go with it. But after the usual /usr/NX/bin/nxserver –keygen, a restart failed with
NX> 500 ERROR: Cannot start service: nxserver NX> 500 Authentication as user nx using the NX SSH key-pair failed. NX> 500 This may be due to the configuration of your SSH server. Please NX> 500 ensure that the location and file name of the SSH authorized NX> 500 keys is the same in both the SSHD and NX server configuration NX> 500 files and that the nx user is listed among the accepted users NX> 500 in the SSHD configuration file. NX> 999 Bye.
Got seriously frustrated, because all seemed well according to documentation. Well, it seems like there is one important step missing – renaming or copying
If you don’t do that, nxserver will happily continue to use its prior key (which makes sense I guess, you aren’t going into production with new keys the second you generate them) while the nx user will already have the new keys in place.
So basically the procedure is:
# /etc/init.d/nxserver stop # /usr/NX/bin/nxserver --keygen # chown nx:root /usr/NX/home/nx/.ssh/authorized_keys2 # chmod 0644 /usr/NX/home/nx/.ssh/authorized_keys2 # chown nx:root /usr/NX/home/nx/.ssh/default.id_dsa.pub # chmod 0644 /usr/NX/home/nx/.ssh/default.id_dsa.pub # cp /usr/NX/share/keys/default.id_dsa.key /usr/NX/share/keys/server.id_dsa.key # /etc/init.d/nxserver start
Of course, your client(s) will also need to import the new server key.
If you get the dreaded
'Cannot run /etc/X11/xdm/Xsession ...'
when requesting a new session on an Ubuntu server, this – at least for me – fixed it:
sudo mkdir /etc/X11/xdm && sudo ln -s /etc/X11/Xsession /etc/X11/xdm/Xsession