Dear everyone,
apologies for the intrusion, and for the talkative message... feel
free to discard on the basis of TL;DR or OT.
I have some noob experience to share, and this looks like a pretty
good place to document the status quo in its breadth.
I haven't found a companion "users" mailing list - so with a shaking
hand, I'm posting here.
Whether you care to read this or not, your comments are welcome.
# Intro and background
-----------------------
I'm still a script kid, despite my bodily age racing forward.
And in my private life / hobbies, I'm proud to be a DIY freetard.
Where I live, in the Czech Republic in the post-commie eastern EU,
terrestrial TV reception has a long tradition. The analog darkness
came about in cca 2012 if memory serves - since then, we've been left
with DVB-T, and it's been a semi-positive experience.
("digital" makes debugging antenna systems more difficult with just
your naked eye, and there's wireless data barking at us just outside
the fences both above 800 MHz and below 470 MHz, etc.)
DVB-T is an old story. But, within about 1 year, DVB-T will pass away
too, and we'll be left with DVB-T2 (actually maybe more like just
half a year from now, allegedly, in our particular area).
Our flavour of DVB-T2 is characteristic by HEVC encoding and
apparently we will enjoy a high percentage of free-view programs (if
not all, in the terrestrial transmission). Not sure if "enjoy" is the
right vocabulary for various reasons, but that's a different story.
We will probably have some public TV channels in full HD and a flock
of commercial channels in QHD and low bitrate, tightly packed in just
a few "networks" (multiplexes) in massive wide-area SDN.
Obviously the world around is not standing still, there's the
satellite coverage, there's IPTV in various flavours, even the late
nineties twisted telco copper in the ground is still alive and
kicking on VDSL2 steroids (FTTH won't happen for a long time) etc.
Youngsters spend more time on YouTube than watching classic TV etc.
It almost feels like I'm "late and to the wrong party", trying to
make DVB-T2 work for me...
I myself have lived through the DVB-T era with a Vestel T816
twin-tuner PVR, which has its glitches but is generally bearable, and
has some features that are shining bright, such as the massive
tabular EPG with an integrated recording/scheduling capability.
I have revamped two pieces of this PVR in my family with solid poly
caps and that's how they will both manage to live to reach moral
obsolescence in reasonable health.
I like the PVR box being separate from the TV display.
During the last year or two, I've been trawling the market for a
replacement, capable of DVB-T2 - and all that I could see were
small-brand PVR machines, imported in small quantities by... small
traders, sometimes having downsides that make them impractical for
our DVB-T2 flavour etc. Significantly more expensive than the old
Vestel box, although not much better in terms of bells and whistles.
# Enter "Linux media" and HTPC
------------------------------------------
And, I've been eyeing the HTPC segment as well - wondering what it
would take, or if it's possible at all, to build a "DIY twin-tuner T2
PVR" using an x86 ATOM motherboard and some general-purpose Linux as
the underlying OS. I know I know - there are the Raspberries and
Odroids and specialized ARM SoC's that can do HEVC better than a
Gemini Lake... but to me that's at the cost of some x86 freedom.
Apparently I'm not alone - there's a small group of people in this
country, who are tinkering in vaguely the same direction, including
some who have been using Linux-based DVB-T headends for several
years.
I have a nifty old RTL2832U dongle for SDR, especially useful
with RTLSDR-scanner, for tuning the antenna systems for my family.
Obviously that's well supported in Linux and DVB-T only.
In order to "test the water", I decided to buy a basic USB dongle
with DVB-T2 capability and see if I can make it work.
Friendly people in a local Linux forum have suggested two or three
models of cheap hardware. Last year there were still some "Astrometa
clones" with RTL2832P, with plausible driver support, which
apparently have vanished from Aliexpress in early 2019 or so.
Another tip was a local importer selling the Mygica T230C2 (sold
relabeled under a local private brand) - it is universally available
around here and the word was, that it can be made to work in Linux,
at the cost of some driver patching and kernel compilation.
To sum up, my goal for the trial was:
to plug in the Mygica, connect it to a decent antenna, scan the band,
and get some moving picture (even if just a "slide show") on the
screen, on scrap x86 hardware, to see that the signal chain is
basically feasible, subject to further fine-tuning on tailor-made
hardware for production use, if that route looks fruitful.
# Speaking of hardware
-------------------------------
For my distro-tourism venture, I'm using a retired notebook PC.
The "platform" is a 65nm Core 2 Duo with i965GM north bridge
(containing the GMA-X3100 mobile IGP) with 2 GB of RAM.
The system is nowadays too feeble for modern Windows,
but feels fair enough for a basic Linux setup.
Fair enough, except possibly the VA capabilities - more on that
below. I used to think that software decoding would be okay for the
"proof of concept", but modulo practical software available, that
guess was possibly too casual.
To feed the Mygica, I'm taking signal from an antenna system that
I've been managing for years on our small residential block, on the
cheap side. It's fine-tuned for the DVB-T transponder set that will
soon become a matter of the past, but it also allows some T2
transponders through, as the amp stack is not a proper "crate of
highly selective channel blade inserts" - rather, the channel
amplifiers are somewhat broad, so the nearby temporary T2
transponders get through as well. By various measures, I'm keeping
the CDMA and LTE interferences at bay, and I've somewhat de-tuned a
nearby DVB-T transponder that's very strong, despite transmitting
mostly junk programs (only good at overloading my headend PA).
I'm keeping the aggregate TX output of the headend's power amp
just below the level where THD starts to hamper reception for the
clients.
In the house, I have several DVB-T and T2 receivers (among my
neighbors) as a general "ballparking benchmark" of how the antenna
system is doing, and I can judge details by RTLSDR_scanner.
# Kernel space: the driver
-------------------------------
I was aware in advance, that the Mygica T230C2 was not supported in
the vanilla kernel. I checked that in the "head" at git.kernel.org,
in drivers/media/usb/dvb-usb/cxusb.c.
A local fellow tinkerer calling himself "no_body" has proposed a
small patch set to vanilla, that would allegedly get the dongle to
work.
https://gist.github.com/dev-as-nobody/55e83fdb57601407a343de78685331be
No_body himself did not submit the patch to vanilla upstream because
he felt that his mod was too simple, the changes to demod init would
not properly cater for the older T230 and T230C.
The older models did not bother me, so I massaged this patch into
5.0.8 vanilla, which did not take much effort (there are differences
to the original patch target i.e. 4.15.12, but the surrounding
context is limited enough for me to understand.)
So I patched 5.0.8: added the PCI ID's into cxusb.c, also extended
the "index enum", modded the demodulator driver to add the extra init
commands, and... it turns out that no_body's mods still lack an
update to the tuner hookup/init. I ended up with an error message
from cxusb complaining about "unknown chip version Si21128",
referring to the tuner (si2141 was expected).
Apparently CrazyCat has noticed that problem years ago:
https://tvheadend.org/boards/5/topics/10864?r=22487
and at the time he opined that, rather than a different chip version,
it seemd that the expected tuner chip was at a different I2C address
(or a different I2C host port? = my impression.)
In the current cxusb driver from CrazyCat, this problem is corrected.
https://bitbucket.org/CrazyCat/linux_media/src/latest/
I took a closer look at the function called
cxusb_mygica_t230_frontend_attach()
in cxusb.c. In the vanilla, that only knows the T230, this is a
single function.
In his version of the driver, CrazyCat has two flavours of the
frontend-attach function: one for T230, and a second version for
T230C and T230C2. And, the contents of that function have changed
significantly. Where the vanilla is using a rather crude and direct
I2C access, CrazyCat has wrapped the tuner-related init into
dedicated functions (apparently doing tuner chip auto-detection) and
provided for the demod init code to be aware of what particular T230
sub-model it's dealing with.
It looks like a nice cleanup on part of CrazyCat, and not a trivial
one = I decided not to try to "port" those changes back into vanilla.
https://bitbucket.org/CrazyCat/linux_media/src/latest/drivers/media/us
b/dvb-usb/cxusb.c
Instead, I downloaded CrazyCat's driver.
There are two options: I could download CrazyCat's whole kernel (some
5.0-RC) or build just the driver (media subsystem) out of tree.
I chose the latter - with the "media_build" script by CrazyCat this
is very easy, and it allows me to choose a kernel version that I like
best. I chose 5.0.8 and later in my distro-tourism 5.0.10 (latest
stable at the time).
As it turns out, a minor trouble with this is, that the driver built
"out of tree" will taint the kernel (although it doesn't contain any
binary blob). Ahh well... I respect that the kernel devs do know what
they're doing.
Once the driver got compiled and loaded, the T230C2 dongle gets
properly detected and the real fun may begin: in the user space.
(In my case, apparently the dongle would only work right
if plugged in at runtime = if not present during Linux OS boot...
not sure why.)
With the CrazyCat drivers loaded, w_scan starts showing some signs of
life: some multiplexes and programs get detected, and a channels.conf
gets produced. The list of DVB-T / T2 carriers and programs is not
necessarily complete and perfectly correct, but it's a fairly good
start.
Unfortunately, CrazyCat's DVB driver stack is perhaps not 100%
API-compatible with the vanilla stack - which probably requires me
to recompile pretty much all user space DVB software against
CrazyCat's header files... :-( This may seem limited to only to the
immediate back-ends of PVR apps, but other reasons may force you to
recompile the "user interface" layers as well, basically if the
packaged software in the distro repos is outdated for DVB-T2,
or too old for the PVR/headend backend software, that just got
updated and recompiled. Dependency hell.
# What's worse than the kernel? The user space.
---------------------------------------------
I was aware beforehand, that DVB-T2 is still somewhat "hot news"
to Linux software - curious as it may sound, after years of field
trials and gradual production roll-out taking place around here.
I knew I'd have to aim for fresh versions of all the software.
# Debian
------------
Initially I started my experiments in Debian 9.8.
I know that the distro is conservative, and the versions of
everything in the Debian "stable" strain is a little dated
- but I like the stability and I thought that perhaps I could cope,
at the cost of downloading some stuff from upstream sources.
So I wasn't very surprised that I needed to compile fresh versions
of many things from source, including some dependencies.
A fresh version of VDR was fairly undemanding, but a VDR output
plugin would require a fresh VAAPI support (libva) and a fresh
ffmpeg, which are moderately difficult to compile (lots of
dependencies).
I took a look at the list of compilation dependencies of Kodi (like
an A4 page of dense print), considered the relative difficulty of
configuring a tvheadend, and skipped Kodi altogether - did not want
to compile this from source.
Actually I tried booting a USB stick with the latest LibreElec
(featuring Kodi 18.1) but the prebuilt live image did not contain a
driver for the Mygica (the cxusb module is vanilla) which turned me
off. I've noticed brief hints of a "CrazyCat driver stack option
pack", but for that I'd have to install LibreElec on the disk drive,
and the installer warnded that it would wipe all data (including
non-linux partitions?) which to me was like "why bother".
Based on the feature set, I actually don't like Kodi for my simple TV
PVR app very much. It has lots of functions I do not need.
Another mediacenter project in Linux is the MythTV.
Which comes with a useful build script that takes care of
dependencies, and compiles even on Debian 9.8.
After the installationg from source was over, I encountered an
implicit generated MythTV password for MariaDB access, which Google
helped me sort out...
I managed to get pretty far with MythTV, before the screeching halt
finally came. The GUI did start just fine, both the mythtv-setup and
the user front end, I was able to configure stuff - only when I tried
to scan the band, the scanning process would always time out, never
finding a single channel. I have noticed that the scanning submenu
did show the Mygica DVB device and I even found an option to select
from the Mygica's three "sub-devices" (possibly dedicated to DVB-C,
DVB-T and ATSC) but neither of them resulted in a successful channel
search.
I noticed some further notes about MySQL/MariaDB side effects, advice
to uninstall and reinstall the database, or to manually convert
tables from MyISAM to InnoDB storage format... which seemd a little
"over the top" to me, and not necessarily at the core of my problem.
Later in the logs somewhere I have noticed an error message roughly
along the lines of "couldn't read DVB response".
All in all I would bet that MythTV compiled against the
systemwide/vanilla "v4l / linux media / uapi kernel headers", whereas
the driver stack was CrazyCat's... and I haven't found a way of how
to point the MythTV build script to the CrazyCat headers.
The CrazyCat's "include" directory actually contains some other
modified header files, outside of the uapi subtree. I'd probably need
to somehow prepend -I/$CRAZYCAT/include/linux/ into the CFLAGS, which
I did not know how to do.
Which was when I gave up on MythTV as well.
The third mediacenter package that I turned my attention to, was the
VDR. Surprisingly to me, this project is apparently less popular
around here, compared to Kodi and MythTV.
There are several things that I like about the vdr:
1) it seems more compact than the other two, and there's more overlap
between its feature set and my personal requirements.
2) The GUI seems sweet: clean cut, lean and mean.
3) the principal author / maintainer is a German citizen, and IMO the
Germans are front runners in DVB-T and now T2 deployment. Chances are
that the community around VDR and its plugins could have all the
constituent toys in relatively good shape.
4) it comes with a build system that allows me to redirect the
include path to the CrazyCat subdirectory.
So I tried compiling VDR from source. VDR 2.4.0 with all the
"developer" patches, which applied cleanly.
First on the Debian 9.8.
I managed to get all the dependencies.
When I faced errors against the Debianese (understandably reatively
stale) VAAPI and FFMPEG, I recompiled those relatively big projects
from source as well, in several iterations, as I kept finding out
./configure options that I'd missed the first time around...
Curiously to me, the VDR does not have an inherent "display front
end" out of the box. It relies on "output plugins", all of which
appear to be 3rd-party projects. The output plugins have had quite a
history of their own during the years, and it happens to be somewhat
difficult to get "just something simple to display the GUI and video
on my X desktop or DRI FB", while being up to date.
And the final result was, that I didn't manage to make it all work in
Debian 9.8. The VDR itself did seem to work, did report locking onto
a DVB-T TS, but the output plugins compiled from source would all
result in a black screen. Either with an error message hinting at an
attempt to free() a null pointer, or with a silent coredump.
Which I attributed to my obvious gross incompetence as a
maintainer/developer (*cough*).
The w_scan also didn't seem to work quite right, but I left
fine-tuning that for later - and I noticed the wirbelscan plugin for
VDR, with fresh updates, which I hoped could replace w_scan
completely.
At about this point I backed up useful data that I'd gathered so far,
and decided to ditch Debian in favour of something closer to the
bleeding edge. As I'm not a fan of rolling release distroes (Gentoo
et al), I went for the latest proper "release" of a major progressive
distro. I went for Ubuntu.
# Ubuntu
-------------
Two decades ago, I would've looked at RedHat/Fedora.
Today, I chose Ubuntu in general, as that has a reputation for
strapping modern goodies on Debian-testing. And, within Ubuntu, I
went for the newest short-lived release: currently the 19.04 - hoping
that I'd get "reasonably fresh versions of everything for free" as a
starting point, also hoping that the upstream developers of DVR etc.
would be living in this kind of environment as well = that any
compilation from source would have a chance of success.
Which proved to be somewhat right.
The first thing I did, I confirmed that the Mygica is not supported
in the distro kernel. Next, I compiled CrazyCat's media stack out of
tree against 5.0.10 vanilla, and installed that.
I ran w_scan to get a fresh channels.conf.
I noticed that it seems to skip some channels.
Sometimes it would skip DVB-T2 transponders altogether in its output,
but the last time around, it would properly export all the DVB-T2 it
came across, but would skip a major (strongest) DVB-T public TV mux
at 570 MHz (CCIR channel 33)... curious, I may return to that later.
Difficult for me to tell if this is due to bugs in w_scan, or the
cxusb driver, or the Mygica hardware, or if my signal is too weak or
too strong, or not pure enough (THD/IMD from the headend too high)
or what. Subject to further investigation.
Well at least I did get *some* list of channels to play with.
Unfortunately, the original w_scan is no longer maintained.
https://www.gen2vdr.de/wirbel/w_scan/index2.html
The last version is from January 2017.
This is also the distro version.
Maybe I can learn something from the source code,
but otherwise I was hoping to get better results from the wirbelscan
plugin to VDR, which has some more recent updates. And I'd have to
compile wirbelscan from source.
Next, I noticed that the stock VDR build in Disco allows me to get
some SD image on the screen through the stock vdr-plugin-xine,
apparently through software MPEG2 decoding.
Yippee, finally I had a GUI and some picture.
Interestingly, just a single transponder (out of about 4 that I
caught) would get the program streams actually displayed.
It was a single DVB-T mux, probably the strongest on a nearby
hilltop. The DVB-T2 programs would not yield a picture on the screen,
just the VDR GUI saying "no signal". Ho hum. That would hint at some
problem between the VDR backend and my antenna system.
Or maybe XINE cannot display the QHD HEVC ?
Difficult to say... time for that later.
In the commandline stderr from
vdr -P"xine"
I have noticed repeated lines that the "TS is scrambled".
Which is not in fact true... could really mean garbled, rather than
scrambled (encrypted). = yet another hint to potentially follow.
Next, I went on to recompile VDR 2.4.0+patches and some plugins from
source, and as expected, this time I did not need to recompile VAAPI
or FFMPEG.
I managed to compile the wirbelscan plugin
https://www.gen2vdr.de/wirbel/wirbelscan/index2.html
Unfortunately the wirbelscancontrol did not compile, complaining
about some unknown class members in VDR headers (if memory serves).
Without that, I won't ever see wirbelscan in the VDR OSD, if I
understand correctly.
Ahh well.
As I'd like the output path to be as direct as possible,
I went looking for "the children of softhddevice",
itself no longer maintained. The latest appears to be:
https://github.com/pesintta/vdr-plugin-vaapidevice
That compiles, but VDR quits immediately if I try to load that. I'm
attaching the /var/log/messages and /var/log/debug from the time
period while vdr -P"vaapidevice" was trying to start.
Not much interesting in there... apart from
VAAPI: Failed to initialise VAAPI connection: -1899086224 ((null))
I've also tried stracing the vdr with the vaapidevice plugin,
but the only potentially interesting apparition in the strace log
was the hint at /etc/libva.conf . That file was missing.
I tried creating it, specifying only LIBVA_MESSAGING_LEVEL=2
- but that did not change anything, did not yield more log output
in /var/log/debug or some such.
I've found notes that the error message from VAAPI could be due to
the right driver file missing.
Not sure if this is the same symptom, but vainfo indicates something
similar: it says it's trying to load a driver for the video decoding
accel for the i965 IGP, finds the VAAPI driver file and the relevant
entry point, but the init routine returns with an error.
The driver is called
/usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
and it's clearly present on disk, so it is *not missing*.
But, I have my doubt if this driver can actually exploit the i965GM
(GMA-X3100) hardware for MPEG2 video acceleration. The driver is also
known as libva-intel-driver, and supposedly supports MPEG decode
acceleration on younger chipsets only, starting from GMA-4500
(4-series Intel chipsets).
https://wiki.archlinux.org/index.php/Hardware_video_acceleration
Also the debian Wiki offers words of warning with respect to video
decode offload into hardware:
https://wiki.debian.org/HardwareVideoAcceleration
And I've found other people's opinions, that the i965GM was a first
attempt at MPEG video accel, and it didn't turn out quite right in
the silicon, so it's probably not supported in the VAAPI driver that
actually carries the name of that early "video accelerated" chipset.
Anyway so this might be down to my stupid choice of hardware,
i.e. not all hope is lost, I plan to give vdr-plugin-vaapidevice
another go on a more modern motherboard.
To possibly at least see the "VDR compiled from source" in action,
I've tried compiling the XINE output plugin from source.
I've tried three different source packages:
https://packages.ubuntu.com/source/disco/vdr-plugin-xine
https://github.com/mhop/vdr-plugin-xine
https://sourceforge.net/projects/xineliboutput/
I wasn't able to compile either.
Downloading dependencies is all fine,
but every time I end up with a missing C/C++ struct member
in some xine or VDR header - which is where I'm stuffed.
It's curious to me that the VDR source code does not contain an
output plugin for generic PC graphics out of the box, inherently
compatible with the same-version VDR backend - apparently the
principal author has some PCI tuner cards with HW MPEG decode
onboard, and maintains a dedicated output plugin for those.
# closing notes
--------------------
So this is how far I got.
Any hints / ideas are welcome, on any of the links in the signal
chain or software stack.
I'm attaching a handful of log snippets - I hope they don't get
filtered. The largest three files are in a zip, as they contain lots
of compressible repeated
messages.
If you'd like to test something on my hardware setup, just let me
know. I can
try things or maybe I could even arrange remote access to the machine
with
Disco running and the cxusb dongle plugged in - and it doesn't have
to be the
old notebook, I could build something slightly more modern out of
retired
desktop hardware or some such.
I've noticed some patches from CrazyCat in the archive of this
mailing list in
2016-ish, but nothing since then... I can only speculate why he
doesn't bother
to post patches upstream anymore, and I do not want to fan any flames
on this topic. My opinion is that this is sad, apparently he's doing
a good job, his updates to cxusb and the related Silicon Image demod
and tuner code appear to work and look elegant and to the point, in
terms of coding style and structure.
If you've read this far, I'd like to thank you for your attention.
Frank Rysanek
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: lspci.txt
Date: 1 May 2019, 19:09
Size: 3131 bytes.
Type: Unix-text
Attachment:
lspci.txt
Description: Binary data
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: lsusb.txt
Date: 1 May 2019, 19:09
Size: 509 bytes.
Type: Unix-text
Attachment:
lsusb.txt
Description: Binary data
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: vainfo.txt
Date: 1 May 2019, 19:09
Size: 405 bytes.
Type: Unix-text
Attachment:
vainfo.txt
Description: Binary data
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: vdr_vaapidevice_err-out.txt
Date: 1 May 2019, 19:09
Size: 86 bytes.
Type: Unix-text
Attachment:
vdr_vaapidevice_err-out.txt
Description: Binary data
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: vdr_vaapidevice_var-log-debug.log
Date: 1 May 2019, 19:09
Size: 2564 bytes.
Type: Unix-text
Attachment:
vdr_vaapidevice_var-log-debug.log
Description: Binary data
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: vdr_vaapidevice_var-log-messages.log
Date: 1 May 2019, 19:09
Size: 2090 bytes.
Type: Unix-text
Attachment:
vdr_vaapidevice_var-log-messages.log
Description: Binary data
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: vdr_xine_err-out.txt
Date: 1 May 2019, 19:09
Size: 8801 bytes.
Type: Unix-text
Attachment:
vdr_xine_err-out.txt
Description: Binary data
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: w_scan__err-out.txt
Date: 1 May 2019, 19:09
Size: 23842 bytes.
Type: Unix-text
Attachment:
w_scan__err-out.txt
Description: Binary data
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: w_scan__channels.conf
Date: 1 May 2019, 19:09
Size: 4587 bytes.
Type: Unix-text
Attachment:
w_scan__channels.conf
Description: Binary data
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: xine_err_out.txt
Date: 1 May 2019, 19:09
Size: 562 bytes.
Type: Unix-text
Attachment:
xine_err_out.txt
Description: Binary data
The following section of this message contains a file attachment
prepared for transmission using the Internet MIME message format.
If you are using Pegasus Mail, or any other MIME-compliant system,
you should be able to save it or view it from within your mailer.
If you cannot, please ask your system administrator for assistance.
---- File information -----------
File: more_logs.zip
Date: 2 May 2019, 16:29
Size: 61447 bytes.
Type: ZIP-archive
<<attachment: more_logs.zip>>
