[Ffmpeg-devel-irc] ffmpeg.log.20171219

[burek]

[00:08:35 CET] <SortaCore> what would affect a file's duration and framerate, but not its playing speed?
[00:22:51 CET] <klaxa> a rip in space-time
[00:32:21 CET] <thebombzen> SortaCore: what do you mean "playing speed"
[00:32:43 CET] <SortaCore> In VLC it plays at normal speed, the video is of a camera feed with time in it
[00:33:05 CET] <thebombzen> what are you trying to accomplish
[00:33:11 CET] <SortaCore> but VLC shows a framerate that's much lower than the camera actually is, and a duration far higher
[00:33:23 CET] <SortaCore> copying H264 from RTSP stream to MP4 container, without transcoding
[00:33:33 CET] <thebombzen> why not just use ffmpeg
[00:33:35 CET] <thebombzen> and not VLC
[00:33:57 CET] <SortaCore> oh, you misunderstood
[00:34:05 CET] <SortaCore> when I playback the MP4 in VLC, it comes up like that
[00:34:09 CET] <thebombzen> also, recording to mp4 is a bad idea. you should probably record to mpegts, and then remux to mp4 later.
[00:34:56 CET] <thebombzen> mp4 is not designed for anything realtime at all
[00:35:18 CET] <SortaCore> it's not going to be played back immediately
[00:35:25 CET] <SortaCore> it's just recording it without transcoding
[00:35:31 CET] <thebombzen> doesn't matter, don't record a realtime stream to mp4
[00:35:52 CET] <SortaCore> mpeg-ts is mpg?
[00:35:56 CET] <thebombzen> mpegts is mpegts
[00:36:02 CET] <thebombzen> .ts is the usual file extension
[00:36:15 CET] <thebombzen> either way:
[00:36:33 CET] <SortaCore> I'm using C++, not the commandline
[00:36:42 CET] <thebombzen> either way, I wouldn't trust VLC
[00:36:54 CET] <thebombzen> what is the reported framerate of the mp4 file if you use: ffmpeg -i recording.mp4
[00:37:35 CET] <SortaCore> stand by one, houston
[00:45:30 CET] <SortaCore> https://pastebin.com/raw/D4YGZ8ag
[01:11:07 CET] <Aatch> Hi, I have a thread-safety question:
[01:12:27 CET] <Aatch> When using send_packet/recieve_frame, is it possible to have one thread call send_packet until it sees EAGAIN, and have another thread call recieve_frame until it sees EAGAIN?
[01:13:07 CET] <DHE> as long as you hold a lock (you provide your own) while calling the functions in each thread, sure
[01:13:35 CET] <DHE> obivously the same lock...
[01:15:39 CET] <Aatch> DHE: Thanks
[01:16:56 CET] <Aatch> A related question: how much (if at all) do video codecs buffer frames? i.e. should I expect an EAGAIN after sending one packet (assuming no recieve_frame between them).
[01:17:58 CET] <DHE> that is highly dependent on the codec and its settings. x264 could buffer 60 frames or more with default settings, or none if you av_dict_set(&dict, "tune", "zerolatency", 0);
[01:18:36 CET] <DHE> not that I would encourage zerolatency mode
[01:21:01 CET] <Aatch> Hmm, so I probably shouldn't rely on there being a buffer, but I can probably get away abusing the codec's for the proof-of-concept I'm doing. Thanks!
[01:22:58 CET] <SortaCore> ffmpeg.exe rtsp -> mp4 results in frame= 2169 fps=5.4 q=-1.0 size=   23040kB time=00:06:55.03 bitrate= 454.8kbits/s speed=1.03x
[01:52:06 CET] <SortaCore> thebombzen: does any of that help ya
[01:55:39 CET] <thomedy> okay im begging someone for help
[01:55:57 CET] <thomedy> im trying to include ffmpeg as an external library into my c++ program on mac osx 8
[01:56:07 CET] <thomedy> any mac developers
[02:01:49 CET] <SortaCore> thomedy: this is IRC so help may take several hours
[02:03:04 CET] <thomedy> well i am subject to my frustrations anyway... are you available now?
[02:03:26 CET] <SortaCore> I know nothing about mac
[02:03:49 CET] <thomedy> dude im stumpped
[02:04:09 CET] <thomedy> this shouldn't be this hard but i dont think im doing anything crazy its just not working
[02:05:01 CET] <SortaCore> you've compiled it for shared library then?
[02:05:47 CET] <thomedy> i did brew install
[02:06:02 CET] <thomedy> so i let home brew build it.. im downloading the srccode now to try that
[02:09:11 CET] <kepstin> for c++ the thing to note is that ffmpeg is a C library, so you're gonna have to put extern "C" {} around the header includes, other than that, just use pkg-config for compiler and linker flags (homebrew should set that up, I think, although i'm not a mac user...)
[02:09:36 CET] <thomedy> there is a pkg_config in my folder
[02:09:44 CET] <thomedy> and so that means i need extern "c"
[02:09:46 CET] <thomedy> to include
[02:09:52 CET] <thomedy> and #include < wont work
[02:09:56 CET] <thomedy> is that what your saying
[02:10:03 CET] <thomedy> i will have to google pkg-config
[02:10:22 CET] <thomedy> everything is so outdated or swift/objective c related
[02:10:37 CET] <kepstin> you still use #include, but you have to wrap it inside an extern "C" {} block so the compiler knows it's a C include, not C++
[02:14:16 CET] <garyserj> kepstin: thanks
[02:26:16 CET] <thebombzen> SortaCore: that says it's 6 frames per second. is the video supposed to be 6 frames per second?
[02:28:31 CET] <SortaCore> yep
[02:29:00 CET] <SortaCore> but the pastebin has a far higher duration
[02:29:15 CET] <SortaCore> I record for about 30 seconds or so and it turns it into 21 minutes and greater
[02:39:05 CET] <thebombzen> SortaCore: it sounds like you're probably writing the PTS incorrectly
[02:39:30 CET] <thebombzen> or somehow your implementation isn't correctly writing the file
[02:39:41 CET] <thebombzen> as for how to do it properly? I have no idea, I dont' use the API
[02:39:43 CET] <DHE> timebase mismatch maybe?
[03:42:14 CET] <Netun0> Hi, I'm streaming OK but my problem is audio.. will it be possibile in near future to just repeat a audio in ffmpeg?
[04:04:11 CET] <SortaCore> DHE: the time base is set to the RTSP stream's one, 1/90000
[04:04:23 CET] <SortaCore> but I am manually setting the PTS/DTS to framenum++
[04:05:15 CET] <SortaCore> then I do av_packet_rescale_ts on video container time base and video file stream timebase, then multiply both DTS and PTS by two
[04:05:54 CET] <SortaCore> I came up with this method after a good while of strugging to get libx264 to work without complaining about non-monotonic DTS
[04:06:20 CET] <SortaCore> works fine in h264_qsv too, just copy without transcode that's messed up
[04:23:09 CET] <Johnjay> hmm ok
[05:45:10 CET] <SortaCore> without pts/dts manually set, I get Application provided invalid, non monotonically increasing dts to muxer in stream
[08:27:36 CET] <dradakovic> i have ffmpeg running and working fine. But i would like some sort of monitorin to see if specific multicast from it is still active or did it drop. Can i do that locally with ffprobe? I cant seem to join my local ffmpeg streams. I can join the streams from anywhere else on the network
[08:28:05 CET] <dradakovic> I can see it active with tcpdump but i wanted to make a script to check for activity
[08:28:21 CET] <dradakovic> cant put tcpdump in a script. SO ffprobe would be fine
[09:00:32 CET] <hendry> hi, i'm trying to create a webp thumbnail like Youtube does it, but `ffmpeg -i ~/media/out/2017-12-17/MVI_6940.MP4 -vf scale=320:240 -vf fps=1 out.webp` scaling doesn't seem to work. Any ideas where I am going wrong ?
[09:37:06 CET] <jkqxz> hendry:  You can't give it multiple "-vf" options (it just uses the last one).  Combine them into a single filter chain as "-vf scale=320:240,fps=1".
[09:38:11 CET] <hendry> jkqxz: ah
[10:51:35 CET] <SortaCore> DHE/JEEB: any suggestions for keeping a good dts/pts for RTSP H264? Without setting them relative to frame number, I get complaints about non-monotonic increasing DTS when copying the H264 straight from rtsp demuxer to mp4 muxer
[10:52:23 CET] <SortaCore> setting frame number works fine in non-copy and copy, but in copy the duration of the file is completely wrong, 21 mins or greater for a half-minute file
[10:52:31 CET] <SortaCore> (copy being no transcode)
[11:08:15 CET] <Nacht> Hmm. I always thought an IDR frame should have a PPS and SPS accompanying it.
[12:13:11 CET] <SortaCore> is there a reason GitHub needs to keep a HTTPS connection open constantly in the background :p
[12:16:11 CET] <jrabe> are you referring to the websocket connection?
[12:18:40 CET] <BtbN> Isn't it pretty common to keep the http connection open? So it doesn't have to be re-established the next time
[12:21:06 CET] <zash> Don't browsers keep like a ton of connections open?
[12:21:34 CET] <jrabe> they do, and GitHub also uses websockets to push live updates (for example if someone adds a new comment to an issue you have open)
[12:34:04 CET] <SortaCore> yea, keeping connections open while the user has the tab open... or even had it open in the last hour or so...
[14:59:12 CET] <DHE> SortaCore: it also dynamically tracks the little notification icon. so yeah...
[15:59:00 CET] <alexpigment> does anyone know what the use case is for xHE-AAC?
[16:03:47 CET] <alexpigment> nm, ignore the last question. what exactly is the difference between MPEG-2 AAC and MPEG-4 AAC?
[16:04:01 CET] <alexpigment> can I use MPEG-2 AAC inside an MPEG-4 container?
[16:05:33 CET] <DHE> the ".mp4" file format largely has nothing to do with the "MPEG" family of codecs
[16:06:18 CET] <alexpigment> well, if I'm using the native AAC encoder in FFMPEG to create MPEG-4 files with H.264 + AAC, am I using MPEG-2 AAC or MPEG-4 AAC?
[16:07:03 CET] <atomnuker> mpeg4
[16:07:27 CET] <alexpigment> is there a way to create MPEG-2 AAC instead within FFMPEG?
[16:08:16 CET] <atomnuker> yes, -profile mpeg2_aac_low
[16:08:41 CET] <atomnuker> -profile:a mpeg2_aac_low
[16:08:43 CET] <alexpigment> awesome. is there any noticeable change in quality? any loss in compatibility?
[16:09:13 CET] <atomnuker> yes, there'll be a slight loss in quality, there should be an increase in compatibility
[16:09:34 CET] <alexpigment> would 160kbs still be relatively transparent though?
[16:09:36 CET] <alexpigment> er
[16:09:38 CET] <alexpigment> kbps
[16:09:38 CET] <atomnuker> yes
[16:09:45 CET] <alexpigment> that's what I needed to know
[16:09:47 CET] <alexpigment> thanks atomnuker
[16:12:01 CET] <Kingsy> I have a video file, 1080p mkv h264 and when I play it on a blu ray player via usb its jumpy. Works fine on my compujter. What would be the bestway to re-encode it via ffmpeg so it plays smooth on the player?
[16:14:15 CET] <alexpigment> Kingsy: what's the frame rate? what's the bitrate?
[16:15:09 CET] <Kingsy> one second
[16:16:35 CET] <Kingsy> alexpigment: 23.976 fr
[16:16:41 CET] <alexpigment> that should be fine
[16:16:45 CET] <alexpigment> what's the bit rate and level
[16:16:59 CET] <Kingsy> 1536kb/s
[16:17:05 CET] <Kingsy> not sure what you mean by level
[16:17:07 CET] <alexpigment> that's the audio bit rate presumably
[16:17:17 CET] <alexpigment> PCM stereo audio I'm guessing?
[16:18:04 CET] <alexpigment> anyway, here's what I'd recommend:
[16:18:26 CET] <alexpigment> ffmpeg -i [infile] -c:v copy -c:a aac output.mp4
[16:18:42 CET] <Kingsy> alexpigment: the audio is DTS
[16:18:54 CET] <alexpigment> if it's still jumpy, there's something about the video stream that's creating the problem
[16:19:10 CET] <alexpigment> if it plays fine, then it was either a) the MKV container or b) the audio track(s)
[16:19:21 CET] <Kingsy> could it be because its DTS?
[16:19:32 CET] <Kingsy> the content bitrate is roughly 4000 kb/s
[16:19:33 CET] <alexpigment> DTS could be a problem within an MKV container, I suppose, though the player should almost certainly support DTS on a Blu-ray disc
[16:19:35 CET] <Kingsy> but it varies
[16:19:57 CET] <Kingsy> alexpigment: can we convert that too with ffmpeg
[16:20:09 CET] <Kingsy> I don't care if its DTS as long as its reasonable
[16:20:13 CET] <alexpigment> yeah, that's what the command I did above does
[16:20:15 CET] <Kingsy> just to try and cover all bases.
[16:20:29 CET] <alexpigment> it's converting only the audio to AAC and putting it in a more standard MP4 container
[16:20:37 CET] <alexpigment> and leaving the video untouched
[16:20:52 CET] <Kingsy> ah ok! is it worth scaling it down to 720p incase its the software decoder ont he device?
[16:21:06 CET] <alexpigment> Kingsy: I doubt it
[16:21:27 CET] <alexpigment> re-encoding the video is time consuming and will generally cause loss in quality
[16:21:43 CET] <alexpigment> converting the audio from DTS to AAC will probably be unnoticeable to most people
[16:21:47 CET] <Kingsy> thats true I suppoed. but the goal is to get it to be smooth and watchable.
[16:22:01 CET] <Kingsy> if its jumpy it wont cut it
[16:22:14 CET] <Kingsy> so a loss in quality if it makes it smooth is fine really. 720p is still decent
[16:22:21 CET] <Kingsy> but if you say it wont matter than I beelive you
[16:22:23 CET] <alexpigment> Kingsy: please try the command I listed above
[16:22:27 CET] <Kingsy> I know nothing about this stuff
[16:22:28 CET] <Kingsy> ok
[16:22:38 CET] <alexpigment> let me know what you find and we'll go from there
[16:22:48 CET] <alexpigment> it should be a very quick test
[16:24:07 CET] <Kingsy> alexpigment: thanks! I will try it tonight, will you be around tomorrow same tiem? I will let you know what happens :)
[16:25:16 CET] <alexpigment> most likely. if I'm not, just re-ask the question and say that you've ruled out the audio and the container as being problematic
[16:27:37 CET] <Kingsy> ok great. Thanks so much!
[16:28:48 CET] <alexpigment> np
[16:33:44 CET] <Nacht> Is it possible to get 'showspectrumpic' to only draw certain freq (bandwidth) ? I'm only intrested in 200hz to 500hz
[16:39:42 CET] <alexpigment> atomnuker: is there a way to tell in the resultant stream if MPEG-4 AAC or MPEG-2 AAC is being used?
[16:44:42 CET] <alexpigment> when specifying -profile:a mpeg2_aac_low , i get the following warning: "PNS unavailable in the "mpeg2_aac_low" profile, turning off"
[16:45:03 CET] <alexpigment> i'm not sure if that means *turning off PNS* or *turning off mpeg2 aac low profile*
[16:45:17 CET] <alexpigment> and I can't figure out a way to verify either one
[16:58:08 CET] <kepstin> turns off PNS: https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/aacenc.c;h=fa7932d42d71caafc9760e2070ed8faa15004fab;hb=HEAD#l1036
[16:58:47 CET] <alexpigment> that's what I thought. i just can't figure out a way to tell that the stream is actually MPEG-2 AAC LC
[17:05:11 CET] <alexpigment> anyway, I guess it's relevant to point out that MPEG-2 AAC LC's royalty payments are no longer needed as of Dec 4, 2017
[17:05:25 CET] <atomnuker> alexpigment: the only difference between mpeg4 aac and mpeg2 aac is that PNS isn't available in mpeg2 aac
[17:05:28 CET] <alexpigment> but MPEG-4 AAC LC and other variants still require royalties
[17:05:49 CET] <atomnuker> so pns is turned off if you use the mpeg4 aac profile
[17:06:01 CET] <alexpigment> atomnuker: that's my understanding as well. I just am looking for something to say "MPEG-2 AAC LC" when looking at the file
[17:06:09 CET] <atomnuker> not possible
[17:06:14 CET] <alexpigment> ok
[17:06:33 CET] <alexpigment> well, I guess that's what I needed to know
[17:06:35 CET] <atomnuker> in fact, pns should be ignored by any mpeg2 decoders
[17:07:08 CET] <atomnuker> one person did complain that an early-2000 home cinema player didn't decode it correctly with pns so I added that profile switch
[17:07:38 CET] <alexpigment> well, it's good to know I'm talking to the right person then :)
[17:07:40 CET] <atomnuker> I guess that decoder must have been non-compliant as it didn't ignore it
[17:08:03 CET] <alexpigment> a non-compliant decoder? surely not... :)
[17:08:23 CET] <atomnuker> in an early 2000s hardware decoder? its more likely than you'd think
[17:08:35 CET] <alexpigment> I was making a joke
[17:09:07 CET] <atomnuker> I know :)
[17:09:39 CET] <alexpigment> so is PNS just a flag that tells the decoder to add noise?
[17:10:51 CET] <atomnuker> more than that, high frequencies (e.g. from cymbals or "S" from human voice) is essentially just noise
[17:11:03 CET] <atomnuker> noise is hard to encode normally
[17:11:43 CET] <atomnuker> so PNS allows you to skip coding expensive coefficients and just replace them with white noise
[17:11:57 CET] <alexpigment> ok, so there is an actual difference in the encoder then
[17:12:25 CET] <alexpigment> "replace all open hi hats with white noise"
[17:12:53 CET] <alexpigment> those are the hardest things to encode in my experience
[17:13:23 CET] <alexpigment> i can hear 'watery' sounds in open hi hats in most lossy streams
[17:14:29 CET] <atomnuker> yeah, that's spectral leakage, its what happens when the frequencies spread out, both in the time domain (lapped transforms) and frequency domain (quantization)
[17:14:50 CET] <alexpigment> interesting
[17:15:02 CET] <atomnuker> opus solved this issue by using cleverer quantization so its cheap to code noise, but opus has troubles with tones
[17:15:37 CET] <atomnuker> thankfully the tone disadvantage is less than the disadvantage of not being able to code noise efficiently so that's part of why opus is so good
[17:16:13 CET] <alexpigment> ah
[17:17:45 CET] <alexpigment> well, back to the original point, it might be interesting to others to know that using -profile:a mpeg2_aac_low can save a company money
[18:03:07 CET] <termos> calling av_buffersrc_add_frame_flags on full hd frames is taking a lot of memory bandwidth, especially if done multiple times into different filter graphs. My "routing thread" that pushes frames into different filter+encoding threads eat a lot of time. Is there a way around this?
[18:12:53 CET] <ritsuka> alexpigment: why would it save money?
[18:13:37 CET] <alexpigment> ritsuka: because the patent fees for MPEG-2 AAC LC went away on December 4th
[18:13:56 CET] <alexpigment> MPEG-4 AAC LC fees still in effect until 2023 for most countries
[18:17:44 CET] <DHE> termos: are you using reference counted frames? it eliminates the need for copying when frames are passed around. especially if you have a split call in your filtergraph
[18:18:45 CET] <termos> hm, no split call, it's several different filter graphs so I don't think I can use ref counted frames as all the filter graphs can't filter the same frame data
[18:19:02 CET] <atomnuker> termos: are your frames refcounted/
[18:21:55 CET] <termos> no they are not
[18:25:02 CET] <termos> it works well if I have 4-5 encodings, but when it get close to 15 output resolutions there are issues. Doing some proxy scaling before pushing to lower resolution filter graphs lowers the time spent copying by a lot, but still not sufficient. Just wondering if this is a solved problem
[18:26:02 CET] <DHE> if you reference count the frames then the AVFrame effectively is read-only but the same memory is used for all of them. you really should be doing that.
[19:13:00 CET] <alexpigment> i've got a weird one that I could use some help with
[19:13:30 CET] <alexpigment> in the past, I've used a patch to x254's encoder.c file to limit the number of threads that it automatically calculates to 16
[19:13:38 CET] <alexpigment> this helps on systems with low amounts of RAM
[19:14:03 CET] <alexpigment> anyway, trying to rebuild today and when the patch is in place, I get lots of errors
[19:14:23 CET] <alexpigment> patch: https://pastebin.com/3LKzChCj
[19:14:28 CET] <DHE> number of threads shouldn't have that big an impact on RAM usage. lookahead is going to consume WAY more memory
[19:14:31 CET] <alexpigment> errors: https://pastebin.com/QaJYFYcD
[19:14:43 CET] <DHE> line 8 has a misbalanced number of parens
[19:14:55 CET] <alexpigment> oh :)
[19:14:58 CET] <alexpigment> well, there's that
[19:15:03 CET] <alexpigment> I was copying and pasting from an older patch
[19:15:21 CET] <alexpigment> I guess that somehow got changed. Thank you for noticing that
[19:18:17 CET] <alexpigment> DHE: i believe the lookahead threads is based on the max threads value
[19:18:42 CET] <alexpigment> in which case, I think this effectively does the same thing
[19:19:21 CET] <DHE> it's not number of threads. it's number of frames. x264 effectively stores uncompressed frames in memory up to the requested number (assuming nothing caps it)
[19:20:16 CET] <alexpigment> oh you're talking about the rc_lookahead value
[19:20:27 CET] <alexpigment> I believe I already cap that for certain resolutions
[19:21:02 CET] <alexpigment> but either way, capping the threads as I'm doing is very much the difference between being able to encode 4k and not
[19:21:34 CET] <alexpigment> especially if you have a processor with 16 logical cores
[19:47:07 CET] <alexpigment> atomnuker: do you know of an easy way to force -profile:a mpeg2_aac_low for all AAC encoding? editing the source is a lot easy for me than editing all my generic -c:a aac calls to ffmpeg
[19:47:54 CET] <atomnuker> change {"aac_pns", "Perceptual noise substitution", offsetof(AACEncContext, options.pns), AV_OPT_TYPE_BOOL, {.i64 = 1},
[19:47:58 CET] <atomnuker> to {"aac_pns", "Perceptual noise substitution", offsetof(AACEncContext, options.pns), AV_OPT_TYPE_BOOL, {.i64 = 0}, ...
[19:48:34 CET] <alexpigment> is that in aacenc.c?
[19:48:40 CET] <atomnuker> yes
[19:48:42 CET] <alexpigment> awesome
[19:48:45 CET] <alexpigment> thank you very much
[19:48:46 CET] <atomnuker> or "if (avctx->profile == FF_PROFILE_MPEG2_AAC_LOW)" to if (1)
[19:49:59 CET] <alexpigment> the former seems easy enough
[19:50:03 CET] <alexpigment> thanks again
[19:50:52 CET] Action: therage3 blinks
[20:07:51 CET] <sm_> hi, i'm trying to use ffmpeg to pull images from a video every minute. this works fine but when i try to scale the images down, the ffmpeg command doesn't work.
[20:07:58 CET] <sm_> https://pastebin.com/iG44cbBg
[20:08:29 CET] <sfan5> pastebin the output too
[20:11:24 CET] <sm_> output: https://pastebin.com/gyjUWiA2
[20:12:15 CET] <sfan5> i don't see an error message there
[20:12:33 CET] <sfan5> in any case don't pass vf twice and use -vf fps=1/60,scale=320:180 instead
[20:12:51 CET] <sm_> sorry I wasn't clear. no error message comes up but the output seems like it's outputting every single frame - not one every minute
[20:12:55 CET] <sm_> Ok i can try that
[20:15:08 CET] <sm_> @sfan5 passing in vf once looks like it fixed my issue, thank you
[21:38:04 CET] <saml> how can I cut a video file without re-encoding?
[21:38:21 CET] <saml> by googling. thanks
[21:39:12 CET] <alexpigment> saml: did you answer yourself in your second line or what?
[21:39:21 CET] <saml> yup i did
[21:39:24 CET] <alexpigment> ok
[21:39:35 CET] <saml> -vcodec copy -acodec copy -ss
[21:39:47 CET] <alexpigment> yeah
[21:40:07 CET] <alexpigment> one thing to note is that it may not be frame-accurate depending on the gop length of your original video
[21:40:26 CET] <alexpigment> i'm pretty sure you can only cut at I-frames
[21:40:46 CET] <alexpigment> anything else requires a smartcutter like VideoRedo
[21:40:58 CET] <saml> ah i see. i just wanted to cut this 5GB file to something under 1MB where there's problem with ffmpeg
[21:41:04 CET] <alexpigment> ah
[21:41:09 CET] <alexpigment> should be fine then
[21:41:18 CET] <saml> ffmpeg fails at certain point of the video with a bunch of errors. i wanted to isolate so i can show you :P
[00:00:00 CET] --- Wed Dec 20 2017