Required Information:
DietPi version | #!/bin/bash
G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=20
G_DIETPI_VERSION_RC=6
G_GITBRANCH=master
G_GITOWNER=Fourdee
Distro version | 9.6
Kernel version | Linux blacksun 4.14.80-v7+ #1161 SMP Mon Nov 12 18:51:43 GMT 2018 armv7l GNU/Linux
SBC device | RPi 3 Model B+ (armv7l)
Power supply used 5V
SDcard used | SanDisk 16Gb
Additional Information (if applicable):
Software title | Transmission
Steps to reproduce:
Fresh install of transmission
Expected behaviour:
after boot transmission daemon should start
Actual behaviour:
Transmission daemon Fails
Extra details:
[FAILED] DietPi-Services | transmission-daemon failed (Result: exit-code) since Fri 2019-02-01 03:06:47 WET; 9s ago
โ transmission-daemon.service - Transmission BitTorrent Daemon
Loaded: loaded (/lib/systemd/system/transmission-daemon.service; disabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/transmission-daemon.service.d
โโdietpi-group.conf
Active: failed (Result: exit-code) since Fri 2019-02-01 03:06:47 WET; 9s ago
Process: 1486 ExecStop=/bin/kill -s STOP $MAINPID (code=exited, status=1/FAILURE)
Process: 1484 ExecStart=/usr/bin/transmission-daemon -f --log-error (code=exited, status=1/FAILURE)
Main PID: 1484 (code=exited, status=1/FAILURE)
Feb 01 03:06:47 blacksun systemd[1]: Starting Transmission BitTorrent Daemon...
Feb 01 03:06:47 blacksun transmission-daemon[1484]: [2019-02-01 03:06:47.957] JSON parse failed in /var/lib/transmission-daemon/.config/transmission-daemon/settings.json at pos 468: STRAY_TOKEN -- remaining text ""cache-size-mb":"
Feb 01 03:06:47 blacksun transmission-daemon[1484]: [2019-02-01 03:06:47.957] transmission-daemon Error loading config file -- exiting. (daemon.c:693)
Feb 01 03:06:47 blacksun systemd[1]: transmission-daemon.service: Main process exited, code=exited, status=1/FAILURE
Feb 01 03:06:47 blacksun systemd[1]: transmission-daemon.service: Control process exited, code=exited status=1
Feb 01 03:06:47 blacksun systemd[1]: Failed to start Transmission BitTorrent Daemon.
Feb 01 03:06:47 blacksun systemd[1]: transmission-daemon.service: Unit entered failed state.
Feb 01 03:06:47 blacksun systemd[1]: transmission-daemon.service: Failed with result 'exit-code'.
@GulyFMG
/var/lib/transmission-daemon/.config/transmission-daemon/settings.json at pos 468: STRAY_TOKEN -- remaining text ""cache-size-mb":"
Many thanks for the report ๐
Test RPi 3B+:
Unable to replicate our end.
Lets fix the file manually:
nano /var/lib/transmission-daemon/.config/transmission-daemon/settings.json
cache-size-mb and replace the line with "cache-size-mb": 97,dietpi-services restartHumm that's strange, just to put in context after the error i uninstall transmission via dietpi software and delete the folder /var/lib/transmission-daemon/ just to make sure i search for the file settings.json and none was found, after i installed again transmission and it failed again, already solved on my end i just delete the file and let transmission recreate it again and change the value from there.
If you guys can reproduce it maybe we can close the issue. Thanks for this.
Did a new reinstall and had the same error again:
root@blacksun:/# dietpi-services status
[ OK ] DietPi-Services | Root access verified.
DietPi-Services
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Mode: status
[ OK ] DietPi-Services | avahi-daemon active (running) since Fri 2019-02-01 19:53:37 WET; 1min 47s ago
[ OK ] DietPi-Services | nmbd active (running) since Fri 2019-02-01 19:53:37 WET; 1min 47s ago
[ OK ] DietPi-Services | smbd active (running) since Fri 2019-02-01 19:53:37 WET; 1min 46s ago
[FAILED] DietPi-Services | transmission-daemon failed (Result: exit-code) since Fri 2019-02-01 19:53:38 WET; 1min 46s ago
โ transmission-daemon.service - Transmission BitTorrent Daemon
Loaded: loaded (/lib/systemd/system/transmission-daemon.service; disabled; vendor preset: enabled)
Drop-In: /etc/systemd/system/transmission-daemon.service.d
โโdietpi-group.conf
Active: failed (Result: exit-code) since Fri 2019-02-01 19:53:38 WET; 1min 46s ago
Process: 9452 ExecStop=/bin/kill -s STOP $MAINPID (code=exited, status=1/FAILURE)
Process: 9450 ExecStart=/usr/bin/transmission-daemon -f --log-error (code=exited, status=1/FAILURE)
Main PID: 9450 (code=exited, status=1/FAILURE)
Feb 01 19:53:38 blacksun systemd[1]: Starting Transmission BitTorrent Daemon...
Feb 01 19:53:38 blacksun transmission-daemon[9450]: [2019-02-01 19:53:38.031] JSON parse failed in /var/lib/transmission-daemon/.config/transmission-daemon/settings.json at pos 468: STRAY_TOKEN -- remaining text ""cache-size-mb":"
Feb 01 19:53:38 blacksun systemd[1]: transmission-daemon.service: Main process exited, code=exited, status=1/FAILURE
Feb 01 19:53:38 blacksun systemd[1]: transmission-daemon.service: Control process exited, code=exited status=1
Feb 01 19:53:38 blacksun systemd[1]: Failed to start Transmission BitTorrent Daemon.
Feb 01 19:53:38 blacksun systemd[1]: transmission-daemon.service: Unit entered failed state.
Feb 01 19:53:38 blacksun systemd[1]: transmission-daemon.service: Failed with result 'exit-code'.
Again if you cant replicate it just close the issue.
@GulyFMG
Please can you send me a bug report? I'd like to check the dietpi-software script and system settings.
Absolutely, here you have the reference code 0f9fd083-6309-4a19-8582-bdea43b3c0b9.
If there is anything more I can do to help just ask.
@GulyFMG
Many thanks, apologies for delay, will check when I can.
@Fourdee if you need anything more just ask, like i said before, on my side is already solved, running and backed up. :+1:
@GulyFMG
Very stange, code in your bug report matches current install code.
I was unable to find any reason why this occurring, however, I did find a potential hardware failure with your external harddrive:
[ 169.079134] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm Finalizer: bg 9940: bad block bitmap checksum
[ 169.201923] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm Finalizer: bg 9941: bad block bitmap checksum
[ 169.203157] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm Finalizer: bg 9942: bad block bitmap checksum
[ 169.204296] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm Finalizer: bg 9943: bad block bitmap checksum
[ 315.351445] EXT4-fs (sda1): error count since last fsck: 1162
[ 315.351460] EXT4-fs (sda1): initial error at time 1531903834: ext4_validate_block_bitmap:389
[ 315.351473] EXT4-fs (sda1): last error at time 1549108974: ext4_validate_block_bitmap:387
[ 1601.470181] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm transmission-da: bg 128: bad block bitmap checksum
[ 1601.806753] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm transmission-da: bg 543: bad block bitmap checksum
[ 1601.829876] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm transmission-da: bg 560: bad block bitmap checksum
[ 5005.585647] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm Thread Pool Wor: bg 9921: bad block bitmap checksum
[ 5005.586055] EXT4-fs error (device sda1) in ext4_free_blocks:4977: Filesystem failed CRC
[ 5005.586976] EXT4-fs error (device sda1): ext4_validate_inode_bitmap:101: comm Thread Pool Wor: Corrupt inode bitmap - block_group = 9921, inode_bitmap = 325058577
[ 5005.587524] EXT4-fs error (device sda1) in ext4_free_inode:363: Filesystem failed CRC
[ 6082.549930] EXT4-fs error (device sda1): ext4_validate_block_bitmap:387: comm Thread Pool Wor: bg 9922: bad block bitmap checksum
[ 6082.550429] EXT4-fs error (device sda1) in ext4_free_blocks:4977: Filesystem failed CRC
You can use dietpi-drive_manager to run a check and repair on the disk.
The only thing it may be, is a failed update, where the dietpi-software script was not correctly updated. We did have issues with updates in v6.20 which are now resolved in v6.21.
I can only suggest trying to update to v6.21, then see if the issue reoccurs after reinstall.
Thanks for the tip... Already did a drive check and it looks everything is OK now... Do you guys have anything baked in dietpi to check logs? Something like drive manager or dietpi software?
I'm gonna skip this update it breaks a kodi addon for me and it doesn't add anything important.
@GulyFMG
Do you guys have anything baked in dietpi to check logs? Something like drive manager or dietpi software?
Nope, journalctl and dmesg provide everything required, doing a good job actually ๐.
I'm gonna skip this update it breaks a kodi addon for me and it doesn't add anything important.
You mean v6.21 does this?? Then it must be some APT package update, since really v6.21 does not change more than fixing a update bug, introduced with v6.20 in some cases.
Might you tell us which Kodi addon it is? Then we might be able to do something about it ๐.
PVR IPTV simple client... Yeah dmseg is pretty solid... Started using on my early days of Linux... Thanks for the tip journalctl ready found some more things to tweak.
I did some digging and the addon as updated for a new version and to support kodi 18... Updating kodi now...
The comma is missing in the line before
"upload-limit-enabled": 0
should be
"upload-limit-enabled": 0,
an then remove the last comma from
"umask": 7,
to
"umask": 7
this solves the issue.
Good point. The json parser is very strict. All lines in /etc/transmission-daemon/settings.json require an ending comma and the last lime must not have one. I just replicated the error by removing comma in last line:
root@VM-Stretch:~# journalctl -u transmission-daemon
-- Logs begin at Tue 2019-03-05 00:44:30 CET, end at Tue 2019-03-05 00:53:32 CET. --
Mar 05 00:53:31 VM-Stretch systemd[1]: Stopping Transmission BitTorrent Daemon...
Mar 05 00:53:32 VM-Stretch transmission-daemon[3131]: [2019-03-05 00:53:32.882] JSON parse failed in /var/lib/transmission-daemon/.config/transmission-daemon/settings.json at pos 2272: TRAILING_COMMA -- remaining text "}
Mar 05 00:53:32 VM-Stretch transmission-daemon[3131]: " (variant-json.c:95)
Mar 05 00:53:32 VM-Stretch transmission-daemon[3131]: [2019-03-05 00:53:32.882] Couldn't save temporary file "/etc/transmission-daemon/settings.json.tmp.UhTJk5": Permission denied (variant.c:1280)
Mar 05 00:53:32 VM-Stretch systemd[1]: Stopped Transmission BitTorrent Daemon.
Mar 05 00:53:32 VM-Stretch systemd[1]: Starting Transmission BitTorrent Daemon...
Mar 05 00:53:32 VM-Stretch systemd[1]: transmission-daemon.service: Main process exited, code=exited, status=1/FAILURE
Mar 05 00:53:32 VM-Stretch systemd[1]: transmission-daemon.service: Control process exited, code=exited status=1
Mar 05 00:53:32 VM-Stretch systemd[1]: Failed to start Transmission BitTorrent Daemon.
Mar 05 00:53:32 VM-Stretch systemd[1]: transmission-daemon.service: Unit entered failed state.
Mar 05 00:53:32 VM-Stretch systemd[1]: transmission-daemon.service: Failed with result 'exit-code'.
@GulyFMG
This indeed is/was also the reason in your case as your log as well shows:
Error loading config file -- exiting. (daemon.c:693)
On fresh install the error does not show up (Stretch) since the touched/changed settings are not the last line and are all added with comma. But I enhance the way we add these settings. If they do not exist, they should be added to the top (after {) to assure they really require the comma.
Done: https://github.com/MichaIng/DietPi/commit/f080a30beaf68d9805e4e5c1be5d16dbb45a7c73
@MichaIng
I was having the same issue as listed above. I followed Fourdee procedure listed above from Feb 1
@Fourdee
Lets fix the file manually:
- Edit file
nano /var/lib/transmission-daemon/.config/transmission-daemon/settings.json
- Find the entry
cache-size-mband replace the line with"cache-size-mb": 97,- Save changes with CTRL+X then Y, then enter
- Restart services with
dietpi-services restart
and still had a failure with the transmission-daemon.
I then tried what what GulyFMG had done
@GulyFMG
... already solved on my end i just delete the file and let transmission recreate it again and change the value from there.
Deleting the file did solve my issue and I am sorry I did not create a bug report so I am not even sure it is completely the same issue. However I did noice there were some permission changes from the file that was installed to the file that was recreated after I deleted the first file.
Permissions from dietpi-software install
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# ls -l
total 12
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr 2 23:52 blocklists
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr 2 23:52 resume
lrwxrwxrwx 1 root root 38 Jan 12 2018 settings.json -> /etc/transmission-daemon/settings.json
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr 2 23:52 torrents
I then made a backup of the settings.json file, removed the old file and then restarted dietpi-services and the new settings.json file was created with different user and group and permissions. Maybe something is messed up in the dietpi-software changing it over. I have no clue, but I thought it may still be causing grief somewhere along the line. Here's my code start to finish
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# ls -l
total 12
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr 2 23:52 blocklists
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr 2 23:52 resume
lrwxrwxrwx 1 root root 38 Jan 12 2018 settings.json -> /etc/transmission-daemon/settings.json
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr 2 23:52 torrents
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# cp settings.json settings.json-old
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# rm settings.json
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# ls -l
total 16
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr 2 23:52 blocklists
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr 2 23:52 resume
-rw------- 1 root root 2333 Apr 4 20:01 settings.json-old
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr 2 23:52 torrents
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# dietpi-services restart
[ OK ] DietPi-Services | Root access verified.
DietPi-Services
โโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโโ
Mode: restart
[ OK ] DietPi-Services | restart : avahi-daemon
[ OK ] DietPi-Services | restart : transmission-daemon
[ OK ] DietPi-Services | restart : sabnzbd
[ OK ] DietPi-Services | restart : sonarr
[ OK ] DietPi-Services | restart : radarr
[ OK ] DietPi-Services | restart : htpc-manager
[ OK ] DietPi-Services | restart : cron
[ SUB1 ] DietPi-Process_tool > Apply
[ OK ] DietPi-Process_tool | Avahi Daemon (2307) : Nice 0
[ OK ] DietPi-Process_tool | Avahi Daemon (2307) : Affinity 0-3
[ OK ] DietPi-Process_tool | Avahi Daemon (2307) : Scheduler SCHED_OTHER 0
[ OK ] DietPi-Process_tool | Avahi Daemon (2308) : Nice 0
[ OK ] DietPi-Process_tool | Avahi Daemon (2308) : Affinity 0-3
[ OK ] DietPi-Process_tool | Avahi Daemon (2308) : Scheduler SCHED_OTHER 0
[ OK ] DietPi-Process_tool | Cron (2379) : Nice 0
[ OK ] DietPi-Process_tool | Cron (2379) : Affinity 0-3
[ OK ] DietPi-Process_tool | Cron (2379) : Scheduler SCHED_OTHER 0
[ OK ] DietPi-Process_tool | DHCP Client (794) : Nice 0
[ OK ] DietPi-Process_tool | DHCP Client (794) : Affinity 0-3
[ OK ] DietPi-Process_tool | DHCP Client (794) : Scheduler SCHED_OTHER 0
[ OK ] DietPi-Process_tool | Dropbear (900) : Nice 0
[ OK ] DietPi-Process_tool | Dropbear (900) : Affinity 0-3
[ OK ] DietPi-Process_tool | Dropbear (900) : Scheduler SCHED_OTHER 0
[ OK ] DietPi-Process_tool | Dropbear (1607) : Nice 0
[ OK ] DietPi-Process_tool | Dropbear (1607) : Affinity 0-3
[ OK ] DietPi-Process_tool | Dropbear (1607) : Scheduler SCHED_OTHER 0
[ OK ] DietPi-Process_tool | HTPC Manager (2369) : Nice 0
[ OK ] DietPi-Process_tool | HTPC Manager (2369) : Affinity 0-3
[ OK ] DietPi-Process_tool | HTPC Manager (2369) : Scheduler SCHED_OTHER 0
[ OK ] DietPi-Process_tool | Radarr (2356) : Nice 0
[ OK ] DietPi-Process_tool | Radarr (2356) : Affinity 0-3
[ OK ] DietPi-Process_tool | Radarr (2356) : Scheduler SCHED_OTHER 0
[ OK ] DietPi-Process_tool | SABnzbd (2333) : Nice 0
[ OK ] DietPi-Process_tool | SABnzbd (2333) : Affinity 0-3
[ OK ] DietPi-Process_tool | SABnzbd (2333) : Scheduler SCHED_OTHER 0
[ OK ] DietPi-Process_tool | Sonarr (2344) : Nice 0
[ OK ] DietPi-Process_tool | Sonarr (2344) : Affinity 0-3
[ OK ] DietPi-Process_tool | Sonarr (2344) : Scheduler SCHED_OTHER 0
[ OK ] DietPi-Process_tool | Transmission (2318) : Nice 0
[ OK ] DietPi-Process_tool | Transmission (2318) : Affinity 0-3
[ OK ] DietPi-Process_tool | Transmission (2318) : Scheduler SCHED_OTHER 0
[ OK ] DietPi-Process_tool | Completed
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# ls -l
total 20
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr 2 23:52 blocklists
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr 2 23:52 resume
-rw------- 1 debian-transmission dietpi 2232 Apr 4 20:01 settings.json
-rw------- 1 root root 2333 Apr 4 20:01 settings.json-old
drwxr-xr-x 2 debian-transmission debian-transmission 4096 Apr 2 23:52 torrents
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# nano settings.json
root@DietPi:/var/lib/transmission-daemon/.config/transmission-daemon# dietpi-services restart
[ OK ] DietPi-Services | Root access verified.
As you can see the user, group and permission on the settings.json file have all be changed.
I also checked this after all of that too...
nano /var/lib/transmission-daemon/.config/transmission-daemon/settings.json
The cache-size-mb line was set at "cache-size-mb": 4
I changed that to "cache-size-mb": 97 and no issues.
For comparison here are my stats on my board. This is a fresh install of everything
root@DietPi:~# cat /DietPi/dietpi/.version
#!/bin/bash
G_DIETPI_VERSION_CORE=6
G_DIETPI_VERSION_SUB=22
G_DIETPI_VERSION_RC=3
G_GITBRANCH=master
G_GITOWNER=Fourdee
root@DietPi:~# echo $G_DISTRO_NAME
stretch
root@DietPi:~# uname -a
Linux DietPi 4.19.20-sunxi64 #5.75 SMP Fri Feb 8 10:29:25 CET 2019 aarch64 GNU/Linux
root@DietPi:~# echo $G_HW_MODEL_DESCRIPTION
Pine A64 (aarch64)
Power Supply - 5v 2a
SD Card 16GB AData HC10
Hope this can fix the issue.
@Drew80
Thanks for reporting.
Hmm install works well here. We do not change anything about file permissions or locations from the default APT install.
Failing service can have many reasons, in this case either syntax or content of the config files. Can you please paste the output of:
diff /var/lib/transmission-daemon/.config/transmission-daemon/settings.json /var/lib/transmission-daemon/.config/transmission-daemon/settings.json-old
About permissions note that:
lrwxrwxrwx 1 root root 38 Jan 12 2018 settings.json -> /etc/transmission-daemon/settings.json
root@VM-Stretch:~# l /etc/transmission-daemon/settings.json
-rw------- 1 debian-transmission debian-transmission 2325 Apr 7 14:59 /etc/transmission-daemon/settings.json
cp settings.json settings.json-old you copied the actual file without preserving it's ownership. As you run this command as root users, the backup file now also has root ownership while the permission mode is the same. (To preserve permissions e.g. cp -a works.)-rw------- 1 root root 2333 Apr 4 20:01 settings.json-old
rm settings.json you removed the symlink (instead of the actual file), so /etc/transmission-daemon/settings.json still exists.-rw------- 1 debian-transmission dietpi 2232 Apr 4 20:01 settings.json
So everything as expected, permissions are all fine ๐.
@MichaIng
First I'll have to apologize for my lack of Linux knowledge. I know enough to get stuff done, but it may not be done correctly. Thanks for the clarification on a few things.
Here is the output you've requested
root@PineBox:~# diff /var/lib/transmission-daemon/.config/transmission-daemon/settings.json /var/lib/transmission-daemon/.config/transmission-daemon/settings.json-old
15c15,17
< "download-dir": "/var/lib/transmission-daemon/Downloads",
---
> "download-dir": "/mnt/dietpi_userdata/downloads",
> "download-limit": 100,
> "download-limit-enabled": 0,
17,20c19,22
< "download-queue-size": 5,
< "encryption": 1,
< "idle-seeding-limit": 30,
< "idle-seeding-limit-enabled": false,
---
> "download-queue-size": 2,
> "encryption": 2,
> "idle-seeding-limit": 1,
> "idle-seeding-limit-enabled": true,
24c26,27
< "message-level": 1,
---
> "max-peers-global": 20,
> "message-level": 0,
27c30
< "peer-limit-global": 200,
---
> "peer-limit-global": 20,
40,41c43,44
< "ratio-limit": 2,
< "ratio-limit-enabled": false,
---
> "ratio-limit": 1.1,
> "ratio-limit-enabled": true,
43c46
< "rpc-authentication-required": false,
---
> "rpc-authentication-required": true,
48c51
< "rpc-password": "{5c01300fc68c5a8a479b7607bdb8380b640a3b83qkEoV3qE",
---
> "rpc-password": "diet314"Gl0b"l",
51c54
< "rpc-username": "",
---
> "rpc-username": "root",
53c56
< "rpc-whitelist-enabled": true,
---
> "rpc-whitelist-enabled": false,
64,66c67,71
< "trash-original-torrent-files": false,
< "umask": 18,
< "upload-slots-per-torrent": 14,
---
> "trash-original-torrent-files": true,
> "umask": 7,
> "upload-limit": 100,
> "upload-limit-enabled": 0,
> "upload-slots-per-torrent": 3,
If you need anything let me know
@Drew80
Head on to the end: Double quotes within the password need to be escaped to prevent service start!
Okay going through the individual settings:
"download-dir" from default to dietpi_userdata is fine"download-limit-enabled" and "download-limit" is not touched by our installer, so that must come from default APT package install and should be fine as well, and is disabled anyway: EDIT: legacy as well, so not sure why default APT install still ships this settings... Doesn't come from us as mentioned!"upload-limit" + "upload-limit-enabled": Legacy but shipped by APT package and not touched by us."download-queue-size" reduced from 5 to 2 on ARM devices which should be fine"encryption" set to 2 which forces encryption instead of just preferring it. But should not affect service start."idle-seeding-limit" enabled and set to 1 which means seeding is stopped after being 1 minute in idle. Should be fine and not affect service start."message-level" set to 0 to not show any messages by default. Should be fine but of course in case of error level 1 would be good to investigate."max-peers-global" set to 20, so no more than 20 peers overall which should be fine on ARM. But I see now that this is a legacy option, replaced by "peer-limit-global". But at least on my system it does not lead to a service start. However I will replace that in code: https://github.com/transmission/transmission/wiki/Editing-Configuration-Files"peer-limit-global" as well so this was doubled. Setting is deprecated since v1.4 and even on Jessie v2.84 is shipped. So safe to skip this.~Could you try to add "max-peers-global": 20, somewhere into the middle of your settings.json and see if service (re)start fails with this? Perhaps Raspbian ships a newer version which indeed does not allow this setting anymore.~
Further:
"rpc-authentication-required" shipped as true by APT package but defaults to false when removing the shipped configuration. Makes sense generally to force authentication and does not lead to service failure in my tests but could affect it in general I think. Could be tested if setting this to true again leads to failure or not on your case."rpc-enabled": false,"trash-original-torrent-files" we enable this to remove torrent files after imported from watch-dir. Of course this requires write permissions to the watch dir but that one is disabled by default anyway and we do not enable it. Should should not play any role."umask": 18, btw means no write permissions for group members. So when you leave this, e.g. Sonarr or media players won't be able to write to the downloaded files (or remove them after imported e.g.). We set this to 2 which allows write permissions for the whole dietpi group, so all our software. This makes life easier if e.g. you want to move files via Sonarr or add/change metadata with media players and such.Okay now I think I found the reason why your daemon failed to start: "rpc-password": "diet314"Gl0b"l",
Your global password contains double quotes but those are not allowed, at least not without being escaped, possibly by backslash. You current config states that this is added hashed by the web UI, so we should do that as well.
Jep could replicate. Adding the password as diet314\"Gl0b\"l works well, skipping the backslashes leads to service failure. I change our code to replace every " with \" ๐.
Actually it would be best if we hash the password ourself or tell Transmission to do so. This would prevent any special character issue as well. From what I read it should hash the password automatically, but it doesn't: https://superuser.com/a/113652
Since I don't how which hash method it uses I can't add this now. Requires further investigation. However I will leave it with the above fix for now.
PR up and merged: https://github.com/MichaIng/DietPi/pull/2706