This seems ridiculous to me, but AWStats is not configured to count exe or dmg files as downloads. What config file or setting can I change? I tried looking through the documentation but found no mention of anything pertaining to Downloads.
I did find out to add another download section containing my file types here http://antezeta.com/news/awstats, but neither the hits or bandwidth calculations are even close to being correct.
Add an extra section to the end of the awstats.config file. The following example counts *.dmg files:
ExtraSectionName1="Disk Image Downloads"
ExtraSectionCodeFilter1="200 304"
ExtraSectionCondition1="URL,\.dmg"
ExtraSectionFirstColumnTitle1="File"
ExtraSectionFirstColumnValues1="URL,(.*)"
ExtraSectionFirstColumnFormat1="%s"
ExtraSectionStatTypes1=HB
ExtraSectionAddAverageRow1=0
ExtraSectionAddSumRow1=1
MaxNbOfExtra1=100
MinHitExtra1=1
Bandwidth counted is unlikely to match file size times download count. Many downloads will not complete or will be interrupted.
Related
I'm trying to vusb-analyzer.
It requires *.mon log file.
How can I make usbmon log file (*.mon)?
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
The document you linked in your question is actually the answer, please see the sections 1-3.
In section 3, it says:
# cat /sys/kernel/debug/usb/usbmon/0u > /tmp/1.mon.out
This will create a text file 1.mon.out. Its structure is also described in the same document.
Now, how do I know that this is the file to be opened by vusb-analyzer? From what I see, the website of this project doesn't make it clear what the *.mon file is.
However, you can see it in the source code:
https://github.com/scanlime/vusb-analyzer/blob/master/VUsbTools/Log.py#L498
It clearly states, that the program uses the syntax described in the document that you already know:
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
The name of your file doesn't really matter, but if you want it to end with ".mon", you could simply use:
# cat /sys/kernel/debug/usb/usbmon/0u > ~/somefile.mon
Two warnings:
The line with cat I posted here is just an example and in order to use it, you will need to follow the steps in the document (it won't work without enabling usbmon first)
vusb-analyzer hasn't been updated for years and I wasn't able to run it on my machine. Its website mentions Ubuntu 8.10 so I wouldn't be surprised if others had problems running it, too. (For example, in order to reproduce your problem, provide more help).
Even files that have their priority set to "Don't download" seem to be created and fully allocated using rutorrent 3.8 on a Debian box.
I believe this stems from a packet 'accidentally' being received and the files thus being created so as not to waste said packet.
How do I correct this behavior? Is there any way of setting up a script/plugin to automatically delete these files as soon as they're created?
Thanks in advance
You have to edit the ~/.rtorrent.rc file and change or insert the line:
system.file_allocate.set = no
This will prevent rtorrent from fully allocating files during download.
I have a video files in:
/home/private/movies/video1.mkv
/home/private/movies/video2.mkv
/home/private/movies/video3.mkv
I have hardlinks to those mkv files in:
/home/minidlna/videos/video1.mkv
/home/minidlna/videos/video2.mkv
/home/minidlna/videos/video3.mkv
My minidlna share is:
/home/minidlna
The video files show up on the minidlna cilent (my TV) after I do a full rescan of the minidlna share, however, they don't show up if I create new hardlinks with the inotify interval set really low.
The files do show up if they are not hardlinks.
My guess is that there seems to be a problem with minidlna and the way it processes the 'filesystem changes' using 'inotify'. Perhaps a hardlink isn't necessary a 'change' to notify minidlna.
My video library is rather large and continually doing rescans seems very inefficient and takes a long time. I would appreciate if someone can shed some light on this or have a workaround.
I'm running minidlna version 1.1.4
It appears it is indeed a problem with minidlna.
Depending on your use case, maybe you can create the new video file in the minidlna directory and make the one in your private movies a hardlink. The resulting filesystem will be the same, but now the first operation minidlna sees should be a full-fledged create, and therefore work.
Looks like there's no workaround to my exact problem and unfortunately my setup doesn't allow reversing the minidlna share <> hardlink directory.
The only solution I found was to rebuild minidlna RPM with IN_CREATE in inotify.c (more details here - http://sourceforge.net/p/minidlna/bugs/227/)
Hopefully Readynas makes that the default for future builds.
I've been trying to develop my own zip library by reading the Wikipedia article on it, for the sake of learning something new.
My first file is a zipped text file containing 215 bytes. It works really well, and the
End of central directory (EOCD) correctly gives me the offset of the central directory header.
https://i.imgur.com/zKmF52i.png
However, when trying larger files, like in this example a zipped 216 byte text file I can't
seem to find the offset anymore. From the info I've found in the Wikipedia article and from Google, the offset to the central director should be 16 bytes after the EOCD, but the value
at that position doesn't correctly show the offset I'm looking for.
https://i.imgur.com/U9Gwwfh.png
It feels like im missing something about how the data should be interpreted since applications like 7-zip and Windows Explorer can read it fine. What am I missing here?
I posted my own answer to this question which contains a link to a working solution that you could use to learn about this problem.
Link: How does one find the start of the central directory in zip files
I could not believe this: it seems that the zip specification does not allow two different files with the same file name going into one zip file.
In my case I use an external file to specify all the files I wanna zip.
This could look like this:
../Website1/favicon.ico
../Website2/favicon.ico
and there we are, that's not possible, despite keeping the directory structure. You would expect the name to be <../Website1/favicon.ico> rather than but that does not seem to be the case, I get:
"Invalid ZIP request (cannot repeat names in Zip file)"
with WinZip. I tried the same with 7Zip - same result.
Strangely googling did not show many hits that really fit but those I found seem to confirm my findings. That's hard to believe since this limitation is very severe. I actually struggle to understand why this did not hit me a couple of decades earlier.
Am I overlooking something very basic here?
To be precise:
Adding these two files:
C:\Temp\Website1\FavIcon
C:\Temp\Website2\FavIcon
results in a single file; the last Add wins...
This however:
Website1\FavIcon
Website2\FavIcon
results in a zip file that contains both files.