- This topic has 11 replies, 6 voices, and was last updated 15 years, 7 months ago by
.
-
Posts
-
When I tried to start up mt-daapd it just said “File size limit exceeded” and wouldn’t start. However, a few minutes ago I discovered that this error was talking about my mt-daapd.log (optional setting in mt-daapd.conf), that had grown above 2GB. It appears that mt-daapd won’t start if the log file is larger than 2GB.
Maybe this is a feature rather than a bug though, in my case the log file would have kept growing until my root partition was all used up. My logfile had grown very fast becaus of my debuglevel setting, that was set to 9.
Maybe this error should say “Logfile size limit exceeded” rather than “File size limit exceeded”. That would make it easier to understand, I believe. 😀 I use svn-1668 by the way.
Anyway, Thanks for a great piece of software, I use it daily. 🙂
@S80_UK wrote:
Could be a feature of your operating system…? FAT32 has a 2 gig limit for each file.
Hm I don’t think so. But then I’m no expert. I’m running ubuntu server (“2.6.15-26-server”), and my root partition’s filesystem is ext2.
OK, it was only a guess – Ext2 goes to 16G with a 1k block size (larger with larger blocks) so something else is responsible.
@oliver wrote:
When I tried to start up mt-daapd it just said “File size limit exceeded” and wouldn’t start. However, a few minutes ago I discovered that this error was talking about my mt-daapd.log (optional setting in mt-daapd.conf), that had grown above 2GB. It appears that mt-daapd won’t start if the log file is larger than 2GB.
Maybe this is a feature rather than a bug though, in my case the log file would have kept growing until my root partition was all used up. My logfile had grown very fast becaus of my debuglevel setting, that was set to 9.
Maybe this error should say “Logfile size limit exceeded” rather than “File size limit exceeded”. That would make it easier to understand, I believe. 😀 I use svn-1668 by the way.
Anyway, Thanks for a great piece of software, I use it daily. 🙂
The real fix is 64 bit file support. I need to find a >2G *something* to test with, though.
Maybe I should just grow my logs to 2G like you did. 🙂
@rpedde wrote:
The real fix is 64 bit file support. I need to find a >2G *something* to test with, though.
That’s easy (if you run Linux): dd if=/dev/zero of=2gigfile bs=1M count=1025.
This will give you give you 2GB+1MB of zeroes. May even be sent around by mail if compressed. 😉
@solexx wrote:
@rpedde wrote:
The real fix is 64 bit file support. I need to find a >2G *something* to test with, though.
That’s easy (if you run Linux): dd if=/dev/zero of=2gigfile bs=1M count=1025.
This will give you give you 2GB+1MB of zeroes. May even be sent around by mail if compressed. 😉
hrm… yeah, but that’s less than useful, as it isn’t an mp3 file or something I can stream. 🙂
— Ron
@rpedde wrote:
it isn’t an mp3 file or something I can stream. 🙂
Maybe you could copy an mp3 file to the beginning and end of the 2gb of zeros? My first thought was to concatenate 2gb of mp3 files into one, but a core of zeros might be easier… Of course, testing could take quite a while if you have to stream to the 2gb mark before you find errors 😉 (nearly four hours even if it was wave audio)
Steve.
I’m guessing this is why all the video content I have that is larger than 2GB doesn’t show up?
—
Steve
- The forum ‘Nightlies Feedback’ is closed to new topics and replies.