Generated.

[homepage.git] / blog / archive / 2018 / 07 / 07.rss

<?xml version="1.0" encoding="ISO-8859-1"?>
<rss version='2.0' xmlns:lj='http://www.livejournal.org/rss/lj/1.0/'>
        <channel>
                <title>Petter Reinholdtsen - Entries from July 2018</title>
                <description>Entries from July 2018</description>
                <link>http://people.skolelinux.org/pere/blog/</link>

        
        <item>
                <title>Streaming the Linux desktop to Kodi using VLC and RTSP</title>
                <link>http://people.skolelinux.org/pere/blog/Streaming_the_Linux_desktop_to_Kodi_using_VLC_and_RTSP.html</link>        
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Streaming_the_Linux_desktop_to_Kodi_using_VLC_and_RTSP.html</guid>
                <pubDate>Thu, 12 Jul 2018 02:00:00 +0200</pubDate>
                <description>&lt;p&gt;A while back, I was asked by a friend how to stream the desktop to
my projector connected to Kodi.  I sadly had to admit that I had no
idea, as it was a task I never had tried.  Since then, I have been
looking for a way to do so, preferable without much extra software to
install on either side.  Today I found a way that seem to kind of
work.  Not great, but it is a start.&lt;/p&gt;

&lt;p&gt;I had a look at several approaches, for example
&lt;a href=&quot;https://github.com/mfoetsch/dlna_live_streaming&quot;&gt;using uPnP
DLNA as described in 2011&lt;/a&gt;, but it required a uPnP server, fuse and
local storage enough to store the stream locally.  This is not going
to work well for me, lacking enough free space, and it would
impossible for my friend to get working.&lt;/p&gt;

&lt;p&gt;Next, it occurred to me that perhaps I could use VLC to create a
video stream that Kodi could play.  Preferably using
broadcast/multicast, to avoid having to change any setup on the Kodi
side when starting such stream.  Unfortunately, the only recipe I
could find using multicast used the rtp protocol, and this protocol
seem to not be supported by Kodi.&lt;/p&gt;

&lt;p&gt;On the other hand, the rtsp protocol is working!  Unfortunately I
have to specify the IP address of the streaming machine in both the
sending command and the file on the Kodi server.  But it is showing my
desktop, and thus allow us to have a shared look on the big screen at
the programs I work on.&lt;/p&gt;

&lt;p&gt;I did not spend much time investigating codeces.  I combined the
rtp and rtsp recipes from
&lt;a href=&quot;https://wiki.videolan.org/Documentation:Streaming_HowTo/Command_Line_Examples/&quot;&gt;the
VLC Streaming HowTo/Command Line Examples&lt;/a&gt;, and was able to get
this working on the desktop/streaming end.&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
vlc screen:// --sout \
  &#39;#transcode{vcodec=mp4v,acodec=mpga,vb=800,ab=128}:rtp{dst=projector.local,port=1234,sdp=rtsp://192.168.11.4:8080/test.sdp}&#39;
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;I ssh-ed into my Kodi box and created a file like this with the
same IP address:&lt;/p&gt;

&lt;blockquote&gt;&lt;pre&gt;
echo rtsp://192.168.11.4:8080/test.sdp \
  &gt; /storage/videos/screenstream.m3u
&lt;/pre&gt;&lt;/blockquote&gt;

&lt;p&gt;Note the 192.168.11.4 IP address is my desktops IP address.  As far
as I can tell the IP must be hardcoded for this to work.  In other
words, if someone elses machine is going to do the steaming, you have
to update screenstream.m4u on the Kodi machine and adjust the vlc
repice.  To get started, locate the file in Kodi and select the m3u
file while the VLC stream is running.  The desktop then show up in my
big screen. :)&lt;/p&gt;

&lt;p&gt;When using the same technique to stream a video file with audio,
the audio quality is really bad.  No idea if the problem is package
loss or bad parameters for the transcode.  I do not know VLC nor Kodi
enough to tell.&lt;/p&gt;

&lt;p&gt;As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
&lt;b&gt;&lt;a href=&quot;bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>What is the most supported MIME type in Debian in 2018?</title>
                <link>http://people.skolelinux.org/pere/blog/What_is_the_most_supported_MIME_type_in_Debian_in_2018_.html</link>        
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/What_is_the_most_supported_MIME_type_in_Debian_in_2018_.html</guid>
                <pubDate>Mon, 9 Jul 2018 08:05:00 +0200</pubDate>
                <description>&lt;p&gt;Five years ago,
&lt;a href=&quot;http://people.skolelinux.org/pere/blog/What_is_the_most_supported_MIME_type_in_Debian_.html&quot;&gt;I
measured what the most supported MIME type in Debian was&lt;/a&gt;, by
analysing the desktop files in all packages in the archive.  Since
then, the DEP-11 AppStream system has been put into production, making
the task a lot easier.  This made me want to repeat the measurement,
to see how much things changed.  Here are the new numbers, for
unstable only this time:

&lt;p&gt;&lt;strong&gt;Debian Unstable:&lt;/strong&gt;&lt;/p&gt;

&lt;pre&gt;
  count MIME type
  ----- -----------------------
     56 image/jpeg
     55 image/png
     49 image/tiff
     48 image/gif
     39 image/bmp
     38 text/plain
     37 audio/mpeg
     34 application/ogg
     33 audio/x-flac
     32 audio/x-mp3
     30 audio/x-wav
     30 audio/x-vorbis+ogg
     29 image/x-portable-pixmap
     27 inode/directory
     27 image/x-portable-bitmap
     27 audio/x-mpeg
     26 application/x-ogg
     25 audio/x-mpegurl
     25 audio/ogg
     24 text/html
&lt;/pre&gt;

&lt;p&gt;The list was created like this using a sid chroot: &quot;cat
/var/lib/apt/lists/*sid*_dep11_Components-amd64.yml.gz| zcat | awk &#39;/^
- \S+\/\S+$/ {print $2 }&#39; | sort | uniq -c | sort -nr | head -20&quot;&lt;/p&gt;

&lt;p&gt;It is interesting to see how image formats have passed text/plain
as the most announced supported MIME type.  These days, thanks to the
AppStream system, if you run into a file format you do not know, and
want to figure out which packages support the format, you can find the
MIME type of the file using &quot;file --mime &amp;lt;filename&amp;gt;&quot;, and then
look up all packages announcing support for this format in their
AppStream metadata (XML or .desktop file) using &quot;appstreamcli
what-provides mimetype &amp;lt;mime-type&amp;gt;.  For example if you, like
me, want to know which packages support inode/directory, you can get a
list like this:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
% appstreamcli what-provides mimetype inode/directory | grep Package: | sort
Package: anjuta
Package: audacious
Package: baobab
Package: cervisia
Package: chirp
Package: dolphin
Package: doublecmd-common
Package: easytag
Package: enlightenment
Package: ephoto
Package: filelight
Package: gwenview
Package: k4dirstat
Package: kaffeine
Package: kdesvn
Package: kid3
Package: kid3-qt
Package: nautilus
Package: nemo
Package: pcmanfm
Package: pcmanfm-qt
Package: qweborf
Package: ranger
Package: sirikali
Package: spacefm
Package: spacefm
Package: vifm
%
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;Using the same method, I can quickly discover that the Sketchup file
format is not yet supported by any package in Debian:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
% appstreamcli what-provides mimetype  application/vnd.sketchup.skp
Could not find component providing &#39;mimetype::application/vnd.sketchup.skp&#39;.
%
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;Yesterday I used it to figure out which packages support the STL 3D
format:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
% appstreamcli what-provides mimetype  application/sla|grep Package
Package: cura
Package: meshlab
Package: printrun
%
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;PS: A new version of Cura was uploaded to Debian yesterday.&lt;/p&gt;

&lt;p&gt;As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
&lt;b&gt;&lt;a href=&quot;bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;
</description>
        </item>
        
        <item>
                <title>Debian APT upgrade without enough free space on the disk...</title>
                <link>http://people.skolelinux.org/pere/blog/Debian_APT_upgrade_without_enough_free_space_on_the_disk___.html</link>        
                <guid isPermaLink="true">http://people.skolelinux.org/pere/blog/Debian_APT_upgrade_without_enough_free_space_on_the_disk___.html</guid>
                <pubDate>Sun, 8 Jul 2018 12:10:00 +0200</pubDate>
                <description>&lt;p&gt;Quite regularly, I let my Debian Sid/Unstable chroot stay untouch
for a while, and when I need to update it there is not enough free
space on the disk for apt to do a normal &#39;apt upgrade&#39;.  I normally
would resolve the issue by doing &#39;apt install &amp;lt;somepackages&amp;gt;&#39; to
upgrade only some of the packages in one batch, until the amount of
packages to download fall below the amount of free space available.
Today, I had about 500 packages to upgrade, and after a while I got
tired of trying to install chunks of packages manually.  I concluded
that I did not have the spare hours required to complete the task, and
decided to see if I could automate it.  I came up with this small
script which I call &#39;apt-in-chunks&#39;:&lt;/p&gt;

&lt;p&gt;&lt;blockquote&gt;&lt;pre&gt;
#!/bin/sh
#
# Upgrade packages when the disk is too full to upgrade every
# upgradable package in one lump.  Fetching packages to upgrade using
# apt, and then installing using dpkg, to avoid changing the package
# flag for manual/automatic.

set -e

ignore() {
    if [ &quot;$1&quot; ]; then
        grep -v &quot;$1&quot;
    else
        cat
    fi
}

for p in $(apt list --upgradable | ignore &quot;$@&quot; |cut -d/ -f1 | grep -v &#39;^Listing...&#39;); do
    echo &quot;Upgrading $p&quot;
    apt clean
    apt install --download-only -y $p
    for f in /var/cache/apt/archives/*.deb; do
        if [ -e &quot;$f&quot; ]; then
            dpkg -i /var/cache/apt/archives/*.deb
            break
        fi
    done
done
&lt;/pre&gt;&lt;/blockquote&gt;&lt;/p&gt;

&lt;p&gt;The script will extract the list of packages to upgrade, try to
download the packages needed to upgrade one package, install the
downloaded packages using dpkg.  The idea is to upgrade packages
without changing the APT mark for the package (ie the one recording of
the package was manually requested or pulled in as a dependency).  To
use it, simply run it as root from the command line.  If it fail, try
&#39;apt install -f&#39; to clean up the mess and run the script again.  This
might happen if the new packages conflict with one of the old
packages.  dpkg is unable to remove, while apt can do this.&lt;/p&gt;

&lt;p&gt;It take one option, a package to ignore in the list of packages to
upgrade.  The option to ignore a package is there to be able to skip
the packages that are simply too large to unpack.  Today this was
&#39;ghc&#39;, but I have run into other large packages causing similar
problems earlier (like TeX).&lt;/p&gt;

&lt;p&gt;Update 2018-07-08: Thanks to Paul Wise, I am aware of two
alternative ways to handle this.  The &quot;unattended-upgrades
--minimal-upgrade-steps&quot; option will try to calculate upgrade sets for
each package to upgrade, and then upgrade them in order, smallest set
first.  It might be a better option than my above mentioned script.
Also, &quot;aptutude upgrade&quot; can upgrade single packages, thus avoiding
the need for using &quot;dpkg -i&quot; in the script above.&lt;/p&gt;

&lt;p&gt;As usual, if you use Bitcoin and want to show your support of my
activities, please send Bitcoin donations to my address
&lt;b&gt;&lt;a href=&quot;bitcoin:15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&quot;&gt;15oWEoG9dUPovwmUL9KWAnYRtNJEkP1u1b&lt;/a&gt;&lt;/b&gt;.&lt;/p&gt;
</description>
        </item>
        
        </channel>
</rss>